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 a 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 it 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 that 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 trust 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. You 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, et cetera, 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 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 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 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 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 sit around and wait for stuff to happen. Okay. So you need to think about a scalable zero trust architecture. You need to think about putting everything I've 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 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, et cetera.

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 management. 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 CHAP-GPT. 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 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.

In that we can create zero trust by having an 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 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.

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 great thing. So AI is definitely a future for AI in every aspect of computing, but particularly, I think, in identity and access management. So finally, just to kind of just give some context of what I've been speaking about, this is what you might call a typical sort of infrastructure and a flow for how identities work. Should we have an identity bias or a data bias access?

And I think currently at the moment, we focus more on the identity. So should the identity 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 going back to the future here, that we start bringing in a data bias to the access so that we ask the identity, 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're almost saying we don't care what the identity is, we don't really care what its existing 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 pretending to be that. So you need to be able to do stuff which then tells you whether that identity has been hijacked, or 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 place, 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 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 talking about. I call it a path to zero trust.

Obviously, the path can be 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 privileged access controls. And the way that many vendors are working right now, traditionally PAM and also new people like White Swan, is that they're doing that integration for you. And then you should think about implementing adaptive and automated security mechanisms.

And with that, you'll probably be looking at areas of AI to help you or look for a vendor that is also building that in for you. And finally, you need to, like any project that you do in security, cyber IT, et cetera, you need to monitor it and let it evolve because nothing stands still these days. Increasingly, I think 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.

And now I should like to hand over to Vinay. Yeah, glad to be here. A wonderful introduction to Zero Trust.

Hi, my name is Vinay. I'm the founder of White Swan Security, 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 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 the PAM market.

Again, as Paul alluded to, the tax have just increased in scope a lot. Like when I talk to a lot of CISOs and the focus on identity-centric prevention has just been at an all-time high.

Obviously, this is because over-provisioned users. We've actually heard from the polls that service accounts, non-human identities, even third-party contractors, these are always over-provisioned. Nobody thinks about them. Nobody goes and reviews them. And these enable this bypass of the identity defenses. And especially with the legacy accounts, when you look at the next accounts, these orphaned accounts, which nobody's taking care of, these open up the back doors for hackers to come in and then exploit.

Obviously, one of the big things which has happened in the last few years is how can you actually have access be more secure? And that could be zero trust infracess. 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 these two terms, they cut down the service area dramatically.

But what we have seen in implementations is that you need a zero trust network access, some kind of a net scope or Zscaler, together with a jumbox proxy, and along with that, some type of just-in-time governance. Or 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, the endpoint doesn't become a trusted enabler for access.

And even for developers, that is a tool for enabling trusted access. So this leads, obviously, when you actually deploy multiple tools to fragmented identity and access management and of ships flying each other in the night, leading to compliance issues.

Obviously, when you don't have these different consoles for managing these things, the access governance becomes a challenge. And 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 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 have already begun. So we sit at the middle of the identities and the access to resources.

The identities, as we've seen in 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 the cloud S3 buckets or RDS, or it could be your Linux servers. It doesn't matter what. But what you have is the fabric in between, which actually enables access to these resources. It could be static, provisioned resources like permissioning, where you always have these over-permissioned identities. Or you could actually move towards an architecture which is kind of zero-standing privileges.

And then we are a zero-standing privileges platform. We firmly believe in making sure that 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 we always look at it from an 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? Or what is the service account doing? We try to identify what that particular activity is. Which folder is the opening? Which LoL bin or fileless activity is he abusing? The service account, which machines are they actually logging into? What's the activity?

So we create that particular 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 differentiates us from traditional infra access is that we 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 of 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, as I said, we discover the permissions, the identity threats. That means the service accounts, the different type of identities which are coming in, then we actually enforce it.

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-native manner. So all your permissions work, everything works because 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 infracess being referred to in the cloud, but we see a lot of OT as well as the traditional use cases where third-party contractors are accessing it. And 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, like you can have your developers or your service accounts just request 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 actually, so I'm logged in as an end-user, you could say. I've actually have all my different instances which are actually available. This is my AI number, 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 at DevSecOps. I have a few on-prem assets, a few cloud assets, all of them. I'm able to actually see that. So this is 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, Azure, GCP with traditional instructions. That means you upload your JSON files, either you put in your subscription IDs or your project IDs. 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 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 as an admin, you can actually always publish these resources. So we have published all these other resources. And let me just show. So even for these types of things, for GCP resources, you actually have all these different things which you can actually do. So let's publish. A few other resources, which we have. That's good. Okay. So that's all it requires for you to be published. And then if you're really thinking that, how do you actually onboard even on-prem? 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, 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 generated.

And this deep information is there so that you can actually put some additional guard rails 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, 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, I can actually have access to, let me actually request an access, and I can actually get access to a certain policy, that's what it is. Give me five minutes. 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 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, I don't have a RDP certificate, I can request the console access.

So because, let's say I don't have the WhiteSwan 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 have actually been requested. All right. 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 what is possible. So I've actually approved these particular access, and this is all time-based access for these assets. So for example, as an instance, you actually go here, any of these things is, you can actually publish and take care of it. So that's definitely how it works in terms of time-based access.

So here, you have actually the users, the S3 buckets. You can see this is time-bound here. You can see 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, 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 were able to actually do that both for the on-prem as well as the cloud infrastructure. I'll actually stop here. I think I 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 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 going to 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 by far, the one area that is most concerning is service accounts. 46% of people said that was the case. Then third parties, 18%. Contractors, 14%. Developers, 11%. So your trusted developers. And interestingly, non-human identities is 11% 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. I think one of the big things we see, Paul, is service accounts are big. I think once you get hold of the service accounts, it's game over.

The amount of over-permissioning, because again, service accounts are used by humans, but they operate in crontabs, the 11 files. So in order to run that and their activity, nobody's actually looked at how these service accounts are baselined. 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.

A lot of service accounts are actually embedded, what their access patterns are, and then saying that, okay, these are the guardrails which you need to put in. But yeah, to get hold of your service accounts requires a little bit more in depth analysis and tools to actually examine all those different activities. And then dialing that pain back. There's no easy pill to swallow to swallow that service accounts, because if you govern the access, everything, all hell breaks loose.

Right, right. Okay, well, 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 Reddle, 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... We've seen a lot of dynamic activity in the farm market. Typically it gets a bad rap for months or years to actually deploy. Our promise is to actually shorten the time dramatically.

So what we have done in terms of making this easier, like I'll answer the question that way, to make it very much of a self-service, if you can call that a self-service way to onboard it, is that whenever we actually onboard it, the cloud entitlements discovery, the setup of the mesh VPN or the trusted access is very seamless. There's actually no knobs typically we actually employ. 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, if you would just want 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 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 only for on-prem, we just do time-based SSH and RDP certificate. So it's like you just enroll it, it's 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 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, 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 crucially not over-provision access?

Oh yeah, yeah. So great question. So that's exactly how we build the product then. So what we do is like, and obviously we didn't have a lot of time, I'll actually send you a demo across for different people, which involves looking at the platform a little bit more deeper. But the idea is that roles or policies or custom roles, like whatever you can do, you can actually make it as a self-service portal. So the admin actually can define all these different roles or policies which you get from your cloud providers. And 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 accessing it, says that 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 need to access. The 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, that's a big question, but what needs to be present? Solutions, services, policies, et cetera. How quick are 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. PAM is like the number one resistance in the enterprise side, but let me answer this question. So one of the things is that it's kind of a peel back the onion. So for the trusted access, let's say you are doing AWS, Azure, GCP, you can actually achieve everything through right-sized control access. You don't need that native tooling on your endpoints or joining of the mesh VPN. It's very quick.

All you need to do is put in your AWS, GCP, or Azure, 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. So it's very quick. You can actually do that right away.

Now, when you actually get into the service account activity, as I was talking, or you want to actually put in an MFA for certain human identities to come in, you need to baseline a little bit before you actually 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 human users.

Typically, that's the reason why you actually always want to baseline. Typically, the bad rap is PAM works in an allow or a deny. It's like a dictator coming in and 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 other one. So I hope that answered your question.

Yeah, power users are always a challenge, but again, all we require is a SaaS instance. And then if you ever want to extend it to deeper stuff, we have agents, but agents are not required, but they do actually make the solution more complete, especially for service accounts.

Okay, great. One sort of last question, because we're coming towards the end of our time, but just to give you enough time to answer it, what do you see as the top four challenges in infrastructure access in terms of the priority in which you should, or our end users, buyers should address them?

Yeah, so this is a funny thing, right? What I actually see is that, as they rightly put it, the service account access, the service account access quickly followed by third-party access. That's what we see, actually.

And then, especially in larger enterprises, the reason is, again, they don't know who these are. Third-party is much easier. Service accounts are much harder to actually find out, even if you find out, how do you actually get a grip on the activity, and then enforce these guardrails to actually make it happen.

So yeah, so from an access perspective, what we see is the third-party access is much easier, the third-party vendor access. Obviously, that's the number one use case we tackled today, because the cloud infra access is a new use case, which we are beginning to follow. The third-party vendor access, where you're doing just-in-time SSH, RDP, or giving a time-bound URL for your end customers. 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 that it is indeed a service account, and then you need those capabilities to kind of guardrail the service account activity, because most of these accounts, they don't show up in Active Directory, so how do you actually ring-fence it? So you need to kind of find where it is originating, and then 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, I haven't got any more questions right now, so like I said, we are coming towards the top of our time. Vinay, it's been a real pleasure having you with us today, and thanks for explaining so well what WhiteSwan can do for end-users. I hope you who are watching, listening at home, got something out of this.

As I said, it will be available as a recording on the Coupang.co.uk website in a couple of days' availability. Apologies for a few glitches here and there, the first time we've used this new streaming service, but I promise you that the next time you see me, it'll be as smooth as butter. In the meantime, once again, thanks, Vinay, for today. Thank you also for listening in, and thank you, Oscar, my producer in Berlin. So for now, goodbye to everyone. Thank you.