Identity-Centric Zero Trust Infra Access

Hello, good afternoon, good evening or even good morning. Welcome to this webinar from Kuppinger Cole. My name is Paul Fisher and I'm delighted to be joined today by Vinay Mamidi from Whiteswan who are also the sponsor of today's webinar entitled Identity-Centric Zero Trust Infra Access. So a bit of a mouthful but what we're actually talking about is obviously zero trust, how we can turn that into better identity security across infrastructure. So with that, let me just tell you some house rules. You as a listener are muted centrally so you don't need to do anything there.

There will be a poll at the start of the webinar which we can look at the results as well during Q&A and also the Q&A is your chance to ask us some questions about what we've been talking about. And finally, this webinar is recorded so that any of your colleagues can watch it or you can in fact watch it yourself again for future reference. So that'll be in the next few days on KuppingerCole.com. So our agenda is pretty simple.

First, I'm going to talk, then Vinay will talk and then we'll have the Q&A. So with that, let's look at this first poll. We want to know what kind of infrastructure access is most concerning and ungoverned in your opinion. So we're talking about third parties, contractors, developers, service accounts and non-human identities which could be anything that's basically a non-human such as application services etc. So third party, contractors, developers, service accounts, NHI, application services. So we'll leave that up running and have a look at the results later.

So we're talking about zero trust. Zero trust is something that is spoken about a lot these days in cyber security and in identity management circles. It's grown from being maybe a little saying never trust always verify into almost like a science or discipline of its own. It started off with the idea that traditional perimeter-based security is no longer effective which is going back to the days of sort of firewalls when we thought that if you put a wall around an organization not much could get in. But of course we found over time that doesn't work.

So John Kindvag was the guy that came up with the idea for zero trust. Others have developed ever since. Now the thing to say about zero trust is though that quite often people do get a bit caught up in the whole business of trying to become a zero trust organization or have a zero trust architecture or infrastructure. That it almost becomes an end in itself. It becomes a burden and then one thing that we always try to say is that zero trust is not something that you apply. It's not one size fits all.

It is something that you need to think about how much of zero trust you need in your organization. How much of changes you need to make to your infrastructure to actually create zero trust. And the bottom line for me is I often think that does zero trust equal trust? Not necessarily and also some areas of your organization you still need to have some level of trust because implementing zero trust across everything can potentially slow things down. But zero trust is an interesting science.

It's certainly worth looking into but it's something you should not just embark on lightly and decide that it's perhaps going to solve all your identity and security problems straight away. So I talked about customization then. So a little bit more detail about what I mean by that. So zero should align with your own business. It should align with your operational systems. It should align with the way you work with your customers for example where you allow customer access. It should allow how you work with other businesses as well so third parties etc.

And then you need to think more about what your industry is. Say you're in financial services for example or maybe you're in the pharmaceuticals. The types of risks you face are going to be different. That means that some organizations probably need more zero trust infrastructure than others. You need to think about the compliance regulations that apply to your industry and apply to your employees and your partners.

Because again if you are allowing people access to certain documents that have for example personal identifiable information you need to make sure that you have locked down the access to those and that could mean making it zero trust. So you don't just allow standing access. You always ask and verify what this identity needs and whether it should be allowed in access to that data. And again the actual size and infrastructure is crucial to how you implement zero trust.

If you are a global organization for example implementing zero trust across that entire enterprise would probably be a gigantic operation and probably impossible. If you are a small startup say working in retail for example zero trust is probably a lot easier to apply. So what more likely is to happen is that zero trust will be implemented on a case-by-case basis. It'll be based on the organization within the organization as it were. So it might be in certain departments or it might be in a certain subsidiary etc not necessarily a local one and so on.

So there's an awful lot to think about when it comes to zero trust and you should think about these things before you even start to think about how to create a zero trust infrastructure. Now privilege access I see as a cornerstone of this new way of working with identity. Privilege access was traditionally been seen as a method of controlling what used to be called super users or privileged accounts.

Those were people generally were people that had access to parts of the infrastructure or the architecture or the systems or IT that were considered sensitive or were considered the things that they were doing were considered to be a risk if the wrong person had access. So for example an admin may be able to remotely upgrade or install software onto an endpoint things like that. But as the years have gone by we now live in a very very different world. We live in a world which is now dominated by cloud or at least not maybe not in actual terms of deployment but certainly in terms of thinking.

There's no doubt that cloud is the future and that it will become the premier form of infrastructure across all organizations. But we also have different ways of working and the dynamic and fluid way that DevOps or the developers or continuous improvement continuous deployment has become preeminent and for better or worse is now influencing business decisions and IT decisions probably out of proportion to the actual part size of those organizations. But you need to think about there privilege access is not something that is that is standing.

Privilege access can change on a day-to-day even hour-by-hour basis and with that backdrop you need to think about what protective requirements there are. What analytical requirements you have when it comes to monitoring this access which is a lot more difficult when you have free-flowing privilege access. The old days when you had a standard PAM it was quite easy because things would happen fairly routinely and then you could look at the stats etc quite literally. But the key thing here is that we have to shift from what was a prevention mindset.

We prevented other identities from having access to privileged accounts and thought that was enough to a proactive one and a proactive one means exactly what I was just talking about which is the dynamic that now exists within organizations a dynamic that is spreading right through where people expect to have access they expect to have access to things as quickly as possible and they don't wish to know whether that's privileged or not that's for the organization to decide.

They need to do their jobs and you'll also find that as the generations change come through business that millennials and beyond have far higher expectation of what they can get from computing in their organization compared to past generations. They're not prepared to and wait for the stuff to happen. So you need to think about a scalable zero trust architecture. You need to think about putting everything I just said into play and then adopting a modular or a more flexible approach to zero trust. So don't panic don't think oh my god I've got to create a zero trust architecture out of nothing.

No you could create the zero trust architecture in a specific environment or a specific architecture or a specific infrastructure within your organization and it could be for example for your developers or it could be for your financial modelers or whatever it is. You need to think also about integration. You need to think about future compatibility.

You need to think about whether what you design and don't forget cloud zero trust is not something you buy you create it using existing tools such as privilege access management etc but you need to think about make sure that everything that you're prescribing now will be cloud native and able to work in hybrid environments so it can still work with all that legacy stuff but it can work with the new cloud stuff and it should also be future proof as far as it can be so that you can anticipate changes in the future.

And then you've got to look at if you have it, probably do, some form of identity access you may have identity governance you may just have access management you may not have any privilege access but you need to really start to refresh the way that you think about identity access management in terms of this dynamic this zero trust environment so that it isn't just something you bought off the shelf and it does this and this it must be something that in future will do this but it'll do that and it can do this it can do things all at once in different places so identity and access management is changing and within that the privilege access part of identity management is changing and we're seeing things like Kim coming through as well.

One thing that you can't escape at the moment of course is people talking about AI probably in this instance we're not talking about things like chat GPT was we're talking about probably more traditional forms of machine learning but the newer forms of AI will undoubtedly allow IAM and privilege access and zero trust to be leveraged um in a more efficient way AI will certainly help us analyze what's happening it can analyze if the wrong people are getting access etc but the speed in which AI can work is where probably the most exciting part of the future is um in that we can create zero trust by having an almost instant response to anomalous behavior so if an identity whether it's non-human whether it's human whether it's something else if that's possible to be something else then if that sends up a real-time alert or is even stopped in its tracks or however else it is configured that is certainly something that AI is going to help with plus the more mundane stuff because we're talking an awful lot now about role sorry about policy-based access control policy is likely to change as quickly as your operating environment is policy changes as compliance changes policy changes as law changes um and again if you have an AI that has been trained to look at all possible compliance and can see how you need to adapt to new compliance and tell you how to do it that's got to be a thing so AI there's definitely a future for AI in every aspect of computing but particularly I think in identity and access management so finally just to um kind of just give some context of what I've been speaking about um this is what you might call a typical sort of infrastructure and a flow for how identities work and I've got should we have an identity bias or a data bias access and I think currently at the moment we work focus more on the identity so should the identity uh be measured should the identity be analyzed and scanned to see whether it should have access to what the identity is seeking but I think we also need to start thinking almost uh going back to the future here uh that we start bringing in a data bias to the access so that we ask the identity uh why are you looking to access this and again this is where things like AI can help because we can make decisions in an instant on whether that identity should go in so if we put the privilege more onto the data so that the data becomes a thing where you measure the privilege and then you have a way of matching the identity request then we're no longer we're moving even further away from that perimeter and much more into a zero trust environment because we almost saying we don't care what the identity is we don't really care uh what its existing uh profile is but we're saying right now right here does this identity and don't forget this identity could have been now stolen so it looks like it belongs to a proper employee or a third party or a machine but actually it's it's pretending to be that so you need to be able to do stuff which then tells you whether that identity has been hijacked on whether that identity is now coming from where you expect it to and most of all whether it should actually have access to what it's looking for right now and it could be that that identity has never actually asked for this before it could be like I said it's coming from a weird in which place you can then stop it so all of that is happening within our infrastructure we're called business infrastructure and the supply chain and everything else all the identity types and increasingly like I said the zero trust is part of the foundational element and to help create that we're using the traditional PAM tools and including and also now cloud infrastructure entitlement management and ITDR as well as coming along although I don't personally think that ITDR uh it will have as much impact as some people think and so on so this is a way of looking at it actually identity and data are now forming a kind of new privileged access paradigm so just to round up this is a summary of everything I've just been uh talking about a a I call it a path to zero trust obviously the path can be uh very different for different environments but you need to assess the current state and identify gaps in your infrastructure then you need to prioritize the assets and data that you need to secure which is where I'm talking about the data buyers then you need to integrate identity and privilege access controls and the way that many vendors are working right now traditionally PAM and also new people uh like white swan is that they're doing that integration for you um and then you should think about implementing you know adaptive and automated security mechanisms and with that you'll probably be looking at areas of AI to help you um or look for a vendor that is also building that in for you and finally you need to like anything that any project that you do in security cyber IT etc you need to monitor it and let it evolve because nothing stands still uh these days um increasingly you know I think the the average length of a deployment is now something like two years before the governing body thinks about removing it and trying something else so there you have it that is my introduction to how you can start to think about Zero Trust how identity fits into all that um and now I should like to hand over to Vinay yeah glad to be here a wonderful introduction to Zero Trust um hi my name is Vinay I'm the founder of White Swan Security a fairly young startup founded in the last couple of years we're taking a more of a unified way to actually approach the PAM market and we combine the the protection of endpoints servers as well as cloud assets in a single console again today's topic is around identity centric infrastructure access so we'll be focusing mostly on that particular aspect of uh the PAM market again as uh Paul alluded to uh you know the tacks have just increased in scope a lot like you know when I talk to a lot of CISOs um and uh the focus on identity centric prevention has just been at an all-time high obviously this is because you know all provision users right like we've actually heard from the polls that service accounts non-human identities even third-party contractors these are always all provision nobody thinks about them nobody goes and reviews them and these enable this bypass of the identity defenses and especially with the legacy accounts as when you look at the next accounts you know these orphaned accounts which nobody's taking care of you know these open up the back doors for for hackers to come in and then exploit obviously one of the big things which has happened in the last few years is uh how how can you actually have access be more secure and that could be zero trust infra access that's the typical term we've heard for kind of a multi-cloud access multi-cloud hybrid access or secure remote privilege access another term thrown around especially when you're accessing legacy or slash ot environments but you know these two terms they cut down the surface area dramatically but what we have seen in implementations is that you need a zero trust network access some kind of a you know you know net scope or z scalar together with a jumbox proxy and along with that some type of just-in-time governance or you know the consoles are just not there for managing on prem and cloud infrastructure and if you only do the management or the entitlement on the cloud then you don't have effective session management and control and then a lot of times especially when you're onboarding contractors or third-party vendors you know the endpoint doesn't become a trusted enabler for access and even for developers that doesn't is a is a tool for enabling trusted access so this leads obviously when you actually deploy multiple tools to fragmented identity and access management and the ships flying in the and going flying each other in the night leading to compliance issues obviously when you don't have you know these different consoles for managing these things the access governance becomes a and you are you have multiple clouds if you don't have a single pane of glass the unified visibility goes out on a toss.

So what we at WhiteSwan have done again I think a shameless plug because you know we're here to say we are an implementation of Infraaccess and PAM so that you can actually start your zero trust journey or continue your zero trust journey if you've already begun. So we sit at the middle of the identities and the access to resources.

The identities as we've seen the poll could be a human identity or a non-human identity like a service account and all of these identities have access to resources they could be you know their cloud s3 buckets or rds or it could be your you know linux servers it doesn't matter but what you have is the is the fabric in between which actually enables access to these resources.

It could be static you know provisioned resources like permissioning where you always have these over permissioned identities or you could actually move towards an architecture which it's kind of zero standing privileges and then we are a zero standing privileges platform we firmly believe in making sure that like we always go to zero standing privileges giving just-in-time access to those resources. Obviously the way that's actually done for different identities and resources is different. So the first thing which we do is you always look at it from a identity micro perimeter.

So what we do is that we establish in our endpoints and servers or any of our activity we establish what is the user doing right like you know or what is the service account doing. We try to identify what that particular activity is you know which folder is the opening which lolbin or fileless activity is the abusing the service account which machines are they actually logging into what's the activity. We create that particular identity micro perimeter and then what we do is that for those activities which require a human element we're able to actually insert an MFA into it.

We're not an active directory intercept we are more passive and that's how we actually look at either protecting the service account behavior or the human behavior. So with service accounts we kind of guardrail that particular activity with humans we have a time bound MFA which we can throw based on the activity. Apart from that what we do is obviously the access portion which we are talking about today and there we discover the cloud entitlements.

So all AWS, Azure and GCP we discover the entitlements and we are able to actually right size the particular permissions for the different users and then give just-in-time access to those end users. One specific thing which kind of also provide the VPN pipe so that means we create a mesh-based VPN along with the proxy along with the just-in-time access. So we do the entire shebang which you'll require for plumbing and all of this is actually very automated.

So if you kind of summarize it it's basically we do that the mesh-based VPN we do the cloud entitlements we do the just-in-time access all these things together with the device identity to make it possible for developers third-party vendors and service accounts to be guardrailed.

Again these are the few modules which we have that means I said like you know we discover the permissions the identity threats you know that means the service accounts the different type of identities which are coming in then we actually enforce it right like that's a very important thing to look at the identities and enforce them where they actually happen whether it's the servers whether it is the endpoints do that and then provide that particular trusted access either through a web-based console access which is basically the just-in-time access to your AWS console or your time-based RDP or SSH all these things and the last one is that because we are able to actually facilitate this kind of mesh-based VPN connectivity we can actually enable the developers the DevSecOps to bring in their endpoints and participate in that particular mesh-based VPN and get access to their AWS infrastructure in a very cloud manner so all your permissions work everything works because you know all these resources are now appearing natively because your endpoint is part of the mesh VPN.

Again different use cases we see traditionally obviously zero-trust infraccess being referred to in the cloud but we see a lot of OT as well as traditional use cases where third-party contractors are accessing it and you know they don't have to be given over-provisioned access you can actually onboard them give them the just-in-time SSH and RDP with time-based certificates and you can actually protect that or if you shift to the cloud right like you can have your developers or your service accounts just request you know the resources which they want in time and you can actually just give access to that particular instance.

So we'll just jump into this particular demo for a minute. So what I'm showing is this is my different instances which are actually available. This is my AIN number, Binet and this is my Azure resources all these things and this is my on-prem resources that means things which are actually the Windows servers, the Linux servers, all these different things. So this is me as a developer DevSecOps. I have a few on-prem assets, few cloud assets, all of them you know I'm able to actually see that.

Yeah so this is the more of our admin screen which is actually over here and this is my super admin screen which I'm actually taking a look at. So here typically what we do is that we obviously onboard your AWS as your GCP with traditional instructions that means you upload your JSON files you know either you put in your subscription IDs or your project IDs right like and we start that discovery automatically and then the discovery is that we obviously discover all the users along with their permissions and then we also obviously discover all the resources.

What we do over here is there's an option right like you know in terms of what you can actually publish or not publish. So we cover EC2 S3 RDS. We are adding Kubernetes clusters shortly next week but the idea is that like you know as an admin you can actually always publish these resources. So we have published all these other resources and let me just show so like you know even for you know these types of things for GCP resources you actually have that all these different things which you can actually do.

So just you know so like you can let's publish a few other resources which we have that's good okay. So that's all that's all it requires for you to be published and then if you're like really thinking that like you know how do you actually onboard even on-prem like you know can you actually manage on-prem all from a single console. The on-prems are in this endpoint tab where we are able to actually publish any of these machines. So I've actually published this particular Windows machine so that it can be accessed by the developers.

So all these things are there apart from this right like I should say that we have a strong what should I say a strong detection component where we are able to actually take a look at all the service account activity, the access activity, all these other things so that you can get a baseline of what's actually happening in your systems and these are all you know generated and this deep information is there so that you can actually put some additional guardrails on your access and how do you actually curtail your users from accessing it.

So anyway once the resource requests and I'll actually talk about it a little bit when the resource requests come in it's a proper governance systems either for on-prem AWS you know we can actually request the console access any of the individual buckets or the VMs or the RDS buckets. The same thing for Azure and GCP. So the idea is that you are requesting access and then the approval comes for a short time-based interval. Here like you know I can have access to let me actually request an access and I can actually get access to a certain policy you know that's what it is.

So I get these policies and I'm going to actually request access to probably this particular virtual machine as a contributor. And then finally I want to access a kind of RDP maintenance maintenance where I get my time-bound RDP certificate for here. So I do that I can also do one more thing I can also request the console access so because let's say I don't have the white swan agent installed on my endpoint I want to work off my console itself with a time-based console I can do this. So I have all these different things which I've actually you know I've been requested.

So here we have these requests which came in so I just wanted to so I just raised the request for AWS Azure and then I raised it for the console access for the bucket with these different permissions so I actually can approve it. Obviously the approval can be done with slack it can be done through email with service ticket integration I'm just showing you you know what is possible. So I've actually approved you know these these particular access and this is all time-based access for you know for these assets.

So for example as an instance you actually go here you know any of these things is you know you can actually publish and take care of it. So that's definitely you know how it works in terms of time-based access. So here like you know you have actually the users the S3 buckets you can see this is time-bound here you can see the the connect button here it was not there before we've actually enabled the access to the AWS console this is time-based console. I don't have permissions for uploading anything you know just viewing and doing something on my S3 buckets so that's right size.

All these things are actually approved so I get my endpoints okay this is pending for this that's okay because I didn't approve and then on my azure directory I actually get my virtual machines I get my time-based access for that. So I get all these other activities done so that's how we are able to actually do the cloud entitlements, the right sizing, the just-in-time access for that. So we're able to actually do that both for the on-prem as well as the the cloud infrastructure.

I'll actually stop here I think just want to allow some time for Q&A before we're doing that but thanks again we are a unified identity security infrastructure. This is our newest module where we are actually adding the the PAM extensions to manage all the cloud infrastructure and then give the just-in-time access similar to how we can do to on-prem infrastructure. Thank you. Vinay thanks so much for that explanation and the demo. We do have some questions but before that I'm gonna just look at the poll result that we did.

Unfortunately we can't show you the full result on screen but I can read them out. So the by far the one area that is most concerning is service accounts 46 percent of people said that was the case then third parties 18 percent contractors 14 developers 11 so you trusted developers and interestingly non-human identities is 11 percent or so. So I guess Vinay those results are fairly as you might expect although I thought there would be more concern about non-human identities.

That's true yeah no it's you know I think one of the big things we see Paul is service accounts are big you know I think once you get hold of the service accounts it's game over you know the amount of over permissioning you know because again service accounts are used by humans but they operate in crontabs the 11 files so you know in order to run and their activity nobody has actually looked at how these service accounts are baseline so they've just given over permissioning across their environment so dialing it back is actually a humongous task.

So what we've seen is typically in one of our financials is that they actually have seen how the cron jobs are running like you know a lot of service accounts are actually embedded what their access patterns are and then saying that like okay these are the guardrails which you need to put in but yeah you know to get hold of your service accounts requires a little bit more in-depth analysis and tools to actually examine all these different activities and then dialing that dialing that pain back there's no easy pill to solve to solve that in the service accounts because if you kind of govern the access everything the hell all hell breaks loose.

Right, okay well that's thanks everyone for voting on that and I'm sure that as time goes by we'll probably see more concern over third parties and contractors but let's also now turn our attention to some questions and we have this question came from Robert Redl who says what is the effort to introduce such a solution he's obviously talking about yours one-time setup and during operation full FTE just for that.

Yeah so I can answer that again I think always vendors will say it depends but we were actually built around you know this is a you know we've seen a lot of dynamic activity in the farm market like you know typically it gets a bad rap for months or years to actually deploy you know our promises to shorten the time dramatically.

So what we have done in terms of making this easier right like I'll answer the question that way to make it very much of a self-service right like you know if you can call that a self-service way to onboard it is that whenever we actually on onboard it like you set up of the mesh VPN or the trusted access is very seamless there's like actually no knobs typically we actually employ it.

So most of our deployments are actually done within a week so we stand up our SaaS infrastructure on-prem we support both and if you actually don't you know if you would just want a kind of a us to be actually a proxy we deploy it in the proxy and we facilitate access to AWS Azure and GCP but if you actually also want to extend that to protect your endpoints and servers there's an agent which comes in which can actually discover all your discover and protect your endpoints and servers.

So typically what we see is that for trusted access it's definitely less than a week where we are able to get a grip around the just-in-time SSH and RDP. Again the reason for that is we only for on-prem we just do time-based SSH and RDP certificate so it's like you know you just enroll it it's you know going to a zero standing privileges same thing with AWS Azure and GCP it's very quick.

So I would say under a week for any type of cloud intra-access for doing the the baselining of the non the service accounts the endpoints typically takes a little bit longer two to three weeks one week to baseline the activity and then another week to actually put in the cloud entitlements. So again you know in your journey if you're looking at access very quick if you're looking for baselining and kind of putting those barriers around your critical on your service accounts it takes a couple of weeks at least.

Okay next question is from Jens Bertel Nikia I don't suppose I pronounced that correctly but apologies but he says that regarding the cloud entitlements how does that work can it be used to build roles on a need to access and not and crucially not over provision access.

Oh yeah yeah so great question so that's that's exactly you know how we build the product then so what we do is like in a you know and obviously we don't have a lot of time I'll actually send you a demo you know across for different people which involves looking at the platform a little bit more deeper but the idea is that like you know roles you know the roles or policies or custom roles right like whatever you can do you can actually make it as a self-service portal so the admin actually can define you know all these different roles or policies which you get from your cloud providers then you can also create the custom roles and then you can attach these custom roles to services you create in the self-service portal so now developers or DevSecOps who are access it says that like you know in order to access this particular resource I have these roles which are there and they're not like those 500 roles which you see a dump when you access your SC console so you create those roles and then you are able to actually show it in a self-service portal and you can attach them and you can request that for a time bound access for those roles but yeah so it's a it's a need to access that need to access comes in that self-service portal which the admins can then kind of administer so you can publish the resource you can publish the roles it comes together in the self-service portal which your end users can then access in a time-bound manner.

Great thanks very much another great question just coming from Andre Zinsek what are prerequisites for successful deployment okay it's a good question but what needs to be present solutions services policies etc how quick are uses or uses adopted to new system and yeah another good question within the question do you get resistant from power users I guess that is a typical concern oh yeah we get always resistance spam spam is like the number one resistance in the enterprise side but let me answer this question so see one of the things is that like you know it's kind of an peel back the onion right so for the trusted access right like you know let's say you are doing AWS as your GCP you can actually achieve everything through right-sized console access you don't need that native tooling on your endpoints or like you know joining of the mesh VPN it's very quick all you need to do is put in your AWS GCP or as your you know JSONs you upload it the discovery starts and you begin populating your self-service portal what resources to publish what roles to choose and then the different personas which can actually see that right so it's very quick you can actually do that right away now when you actually get into you know the service account activity right like as I was talking or like you know you want to actually put an MFA for like you know certain human identities to come in you need to baseline a little bit before you actually do kind of try to introduce that activity onto these users so I would say that usually takes a week of baselining before you can actually begin to implement any policies which is basically the enforcement policies on the on the human users typically right that's the reason why you actually always want to baseline typically the bad rap is PAM is works in an allow or a deny it's like you know it's like a dictator coming in and like climbing through the goodness about ITDR is that it gives you that nuanced perspective which users are abusing which are the accounts you need to pay attention to you can actually focus your attention there get your wins and then move on to the to the other one so hope that answered your question yeah power users are always a challenge but you know you know again all we require is a SAS instance and then if you ever want to extend it right like you know to deeper stuff like you know we have agents but agents are not required like you know but they do actually make the solution more complete especially for service accounts okay great um one sort of last question because we're coming towards the end of our time uh but just to give you enough time to answer it um what do you see as the top four challenges in infrastructure access in terms of the priority in which you you should or are you know end users buyers should address them yeah so uh so so this is a funny thing right like you know what i actually see is that as does the rightly put in the the service account access uh you know the service account access quickly followed by uh you know third party uh access that's what we see actually and then especially in larger enterprises uh the reason is again they don't know who these uh you know who these are third party is much easier service accounts much harder to actually find out even if you find out like you know how do you actually get a grip on the activity and then enforce these guardrails to actually make it happen um so yeah so from an access perspective um what we see is uh you know the third party vendor access uh obviously that's the uh the number one use case we tackle today like you know because uh the cloud intra access is a new use case which we have begin to uh follow a third party vendor access where like you know you're doing uh just in time ssh rdp or like giving a time bound url for your uh and customers you know these uh these things right like where you're actually just giving that zero standing privileges you're not over provisioning it i would say that actually solves so much of the pain point for the service accounts again you need to really find out where they're lurking find out have a good itdr tool which can actually find out uh you know that it is indeed a service account and then you need those capabilities to kind of guardrail the service account activity uh you know because you know you know most of these accounts they don't show up in active directory so how do you actually ring fence it so so you need to kind of find where it is originating and then uh you know put an agent there and then ring fence that particular activity on that particular server so that nobody is able to hijack it and then do it okay well um i haven't got any more questions right now uh so uh like i said we are coming towards the top of our time uh vinay been a real pleasure having you with us today and thanks for explaining so well um what white swan can do for end users uh i hope you who are watching listening at home uh got something out of this as i said it will be available as a recording on the kubinka col website um in a couple of days availability um apologies for a few glitches here and there the first time we've used this new um streaming service but uh i promise you that the next time you see me it'll be as smooth as butter um in the meantime once again thanks vinay for today thank you also uh for listening in and thank you oscar my producer in berlin so for now goodbye to everyone thank you