We understand that like real time capabilities are extremely important to prevent reaches, stop reaches and remediate them. So we have two core capabilities there that I think are different from the others. One, we use LLMS to improve the visibility and posture capabilities that you have compared to your standard IGA and Palm tools today. But then 2, we are able to do real time detection and response
to identity based threats. And this makes it so that you you're able to catch anything that your identity like governance program might might have missed or anywhere anybody that gets fished, stolen credentials, stolen tokens and so on. The ability to do it real time is something that we think is is lacking in industry. This is identity at the center if it has anything to do with IAM. This is the go to podcast now your hosts Jim McDonald and Jeff Stedman.
Welcome to the Identity at the Center podcast. I'm Jeff, and that's Jim. Hey, Jim. Hey, Jeff, how are you? Oh, not so bad yourself. Good. I'm excited for today's episode. I think the the focus for me is innovation. I talked to a lot of folks who are listeners of the show. They want to know what are the new innovations that are happening? What are the new products that are bringing innovation into the world of I am. So we're going to get into this today.
Yeah, for sure. Today's a sponsored episode. So making that very clear up front, these are episodes where we dive a little bit deeper into the technologies and the the players in the space. And there are a lot of them. So I'm glad that we're able to get some of these folks on and kind of explain, OK, where are they coming from, their viewpoints and things like that. So just make it crystal clear, right? This is sponsored episode today.
We're sponsored by slash ID. They're an identity platform to protect human and non human identities. You can find out more about them at slashid.com/IDAC. And we've got Vincenzo Yoso today. He's the CEO at slash ID Welcome Vincenzo. And hopefully I didn't butcher your last name. You didn't. I'm very impressed. All right. Well, we're starting off on a
great note. One of the things we also like to do before we start to get into any sort of conversations, really find out about the backgrounds of the people that we talked to that are in the identity space. It's a wide and varied space. You've got an interesting 1, so let's start there. How did you get into the digital identity space? Is this something that you chose or did it choose you? It definitely choose me.
So I have. I have a bit of a, a strange background compared to a lot of like your guests in that I, I started my career in sort of like the offensive security side of things and then over time got a closer and closer to identity. So my original background is in security research. I used to work on vulnerabilities and exploits for endpoints. Fast forward, I spent a number of years at Crowd Strike and one of the products that I was involved with at crowd Strike was the identity protection
product. And that's how I started to be involved in, in the identity space. But it's always, it's always has been more from my security standpoint rather than a traditional identity background. And so you take that attack mindset, no better way to start with, like, how do we defend against attackers? And you also do some work, I think, with Black Hat, right? As I was just kind of stalking you on LinkedIn a little bit. Tell me about your Black Hat involvement.
Yeah. So I mean, when I, when I started back in the days on the security kind of like researcher track, I used to do a lot of like presentations on attacks and then like exploitation techniques. And that's how I got involved with Blackett at the beginning. And then I have stayed involved throughout the years to give back to the community and make sure that like we still have like vibrant talks and and interesting tracks at the conference. So I've been put to Black Hat in
the past. It's been a couple years. I always kind of enjoyed it and I've seen some interesting things there. Maybe if we have time towards the end, I'll ask you like what are some things maybe that you've seen that might be kind of interesting there. But let's talk about slash ID. So what is slash Idi guess? Tell us a little bit about the the organization that you're building there and the technology that you're bringing to the digital identity market. Yeah.
So as I mentioned, we, we come to the space from from our security background and what we thought was missing when when we started a company were were really two things. One, everyone we spoke with had problems with IGA processes in the in the sense that they weren't particularly effective. You had a lot of failed implementations and so on.
But more importantly, we had started to see most reaches a crowd strike being identity related where at least either the initial vector or at some point throughout the kill chain you add an identity component. And none of the existing products were focused on identity security rather than compliance and management. So tell me about the name, because slash ID is kind of unique and like there's there's usually a story behind something. How did you come up with slash ID?
Yeah. So what we wanted to convey with the with the name similar to, I don't know if you, if you've ever read the story of Stripe, but their first name was slash payment. And the idea there was to bring kind of like payments to developers and engineers. And what we wanted to do from day one is to build a platform that was friendly to security engineers and practitioners, not just sort of like that click OPS kind of kind of like kind of
product. So I have to say, right, there's a ton of products in this space of digital identity, too many almost to keep up with. And so there's a lot of competition. You know, I'm curious from your perspective, what is it that you think sets slash ID apart from your contemporaries? You know, I guess the the blunt version is what makes you special. Yeah. So I think it's it's really two
things. 1 is a lot of the other companies in the space focus on a static view of the identity, whereas coming from a security background, we understand it like real time capabilities are extremely important to prevent breaches, stop breaches and remediate them. So we have two core capabilities there that I think are different from the others. One, we use LMS to improve the visibility and posture capabilities that you have compared to your standard IGA
and pump tools today. But then two, we are able to do real time detection and response to identity based threats. And this makes it so that you you're able to catch anything that your identity like governance program might might have missed or anywhere anybody that gets fished, stolen credentials, stolen tokens and so on. The ability to do it real time is something that we think is is
lacking in industry. So Vincenzo, the question I was going to ask you was because most of the time when I talk to entrepreneurs in this space, there's something that they recognize in the industry that's kind of overlooked or that they feel they could bring a fresh solution to fix a problem. The question I was going to ask you is what drew you in? But I think you answered that when you talked to to Jeff about, you know, the the IGA situation, not really solving
the problem. I think you talked about the the breaches being mostly identity related. So I want to pick on those two areas. And I've heard it said that, you know, the IGA solutions are better for driving compliance than solving real security issues. So the first is that's something you agree with and and why it? Why is that the case in your opinion? Yeah, 100%.
I mean, when you look at the history of IGA and I think you had guests on on on the podcast that were sort of like the, the real, the, the creators of of IGA as a space. It was primarily been driven by compliance needs in the wake of Enron and similar like fraudulent activities for public companies. So the approach you take when when you use governance is a very prescriptive, policy based approach that doesn't, doesn't really work when you deal with attacks, stereo dynamic in nature.
And what attackers really try to do is to look for gaps in your posture. And it's something that a governance platform is not actually able to react to in a timely manner. Yeah. And so, I mean, I kind of feel like it's this isn't a black and white situation, right. I think most of the compliance regulations try to drive better security through compliance through kind of these governance processes.
So they at least incrementally make security better, going in and checking to make sure people have only the access that they should have. But it seems like most of the processes from a governance perspective are detective and they could be, you know, not performed until some periodic basis, right? Maybe it's once a year. So checking a list of accounts to make sure that they have the right entitlements once a year is good, but not great.
Exactly. I, I think you're far on Jim, like when you, when you, when you look at the problem is an attacker breaks into an environment at any point in time, right. They they don't wait for the compliance audit to come due. And what you see in complex organizations is that these entitlements change by the day. And so taking a snapshot once a year or one supporter is nowhere near enough to be able to detect and attack in real time on top of it. And I'm sure you've seen this as
well. A lot of IGA has become so complex. There's often, there's often just a check box exercise where some manager just says, yes, this, this person on my team should have access to the system, but they don't have the ability to really know how our buck works in that system, what entitlements really mean and and so on. So you have this double whammy where snapshot based solutions are not moving fast enough
compared to attackers. And on the flip side, the complexity of these systems is such that even when you do take a snapshot to make sure that you're compliant, often the the, the, the degree of access control that you can really do is a lot less than what you need for proper security because it's too complicated to understand the authorization model of each individual application that you're dealing with.
Yeah. I mean, as you're talking, I'm sitting here thinking of one of the biggest faux pas within kind of the idea of governance, which is rubber stamping. I mean, I think what happens in organizations is there's two major problems. 1 is the entitlement system is so complex that people don't really understand that Vincenzo has XYZ access. Is that appropriate?
Well, if you put that in front of the wrong person or somebody who doesn't know what XYZ access really means, they say, well, Vincenzo is a good guy, he wouldn't do anything wrong. And so they just say keep it or they're afraid that they take it off. The company's going to stop being able to pay invoices or something, something crazy, right? So there's the not having enough
information around entitlement. So the other thing that I find you don't hear talk about much is that a lot of the decision making is consolidated in very few hands. So one person might be reviewing access for too many people, too many applications and it becomes IAM overload for them. So they're being asked to do all these reviews and they're often the most busy people in the organization to begin with.
So now rubber stamping becomes out of control, especially if you compound it with the first problem. So I guess my question to you is like, how does slash ID solve this problem? Do you actually solve it? Or do you say like the approach is wrong and we do something different? Yeah. So I mean 2-2 of of the so like most loved features of our platform are actually exactly tackling the first problem that you're talking about Jim. And it's it's a very different
way to approach it, we think. So 1 is we like it. This sounds very simple and and stupid in many ways, but like people find a lot of value out of it. We can automatically generate descriptions for roles, identities, credentials and groups in your environment so that you're able to see both us as a identity professional, as a security professional, as well as a business user. Hey, what can this identity actually do? What does it does? Does this identity have access
to in in the environment? And the second thing is to your point about the complexity of the entitlement systems, often, especially when you look at like cloud environments, it's almost impossible to create a use privilege list privilege policy
right from the start. So one of the things that we help companies do is observe the behavior of their identity over time, see which entitlements he actually uses, and then automatically generate a list privilege policy that minimizes the amount of access that an entity has without disrupting disrupting it. Which we think is is fundamentally better approach than trying to be prescriptive and trying to create roles or groups upfront, especially in
environments that have very complex authorization systems. That's a great, great overview. So the other thing that you pointed out was one of the, you know, as one of the things that really drew you into the industry was the whole data breach aside. So truly security trying to solve a security problem that, you know, all organizations at least need to be thinking about. But you made a statement that most of them are identity related.
I think I know what that means being the Co host of the identity to center podcast but I want to know what you mean. Yeah. So when when you look at the various industry reports on data breaches throughout the years, Verizon publishes a very popular 1. AWS also publishes a very popular one yearly. Almost all of them across the board mention identity as one of the primary vector for either the initial compromise or lateral movement. I'll give you some some stats
which which I find extremely interesting. 66% of the bridges that Amazon sees in AWS are due to stalling AWS credentials. About 33% of all the bridges that Verizon tracks have a credential related issue as the entry point and cross strike tracks in their global reports lateral movement attempts. Most of them are actually an anti related where somebody's using cover roasting or similar techniques to escalate privileges within an environment.
And so it really feels like from from our standpoint that most of the identity programs out there are not doing enough on the security side and that's why we're seeing such a spike in identity related breaches. Yeah. You know, I read a recent report which pointed out that I identity related breaches have dropped over the past five years. And I feel like I, you know, they're not as persistently in the news.
But the guidance in that report and guidance that kind of rings true to me is that even though the the number of them may be falling, they're the impact, the risk is still there, right? The impact outweighs maybe the likelihood, and maybe the likelihood is dropping because of people doing better identity
management. I, I think the, what, what I will say is if, if you look at like the, the, the latest Verizon report that just came out, I think like today or, or, or last night, what you'll see is there is a spike in vulnerabilities as the primary attack vector as opposed to credential breaches. But credential breaches are still so far the number one cause for, for, for, for, for
breaches. I think what what what's happening over time is we're moving as an industry away from long lived access tokens to better ways to authenticate services and machines and so on. But we're still far away from like identity being sort of like a secure part of the IT stack. Yeah. I mean, look, the problem is not going away. By the way. The the report that I was referencing is the RSMUS Middle Market Business Index special report.
And kind of the, what I thought was the punchline is even though the data is positive, there was a spike in in breaches in 2024, but that the methods being used in these attacks are becoming more sophisticated. Some attacks may go undetected. And that highlights the importance of continuously strengthening security controls. It's that undetected piece,
right? That's the that's the real hook that you know, people get in the door and then they sit there and then they conduct their attack later after they realize you don't even know that I'm in. Yeah, no. And honestly, Jim, you're, you're really into something on this because when you look at the average what what people in the security industry called the well time is the amount of time that an attacker stays in an environment before being thrown out for a normal breach that is 10 days.
This is across the board from like Google reports, cross right reports and so on. When you look at identity based bridges, most of them take over a month to be discovered. And the reason for it is that we just don't have the same degree of detection capabilities that we have compared to endpoint security or cloud security. So I think a big part of what we're seeing, Jim, is that these breaches are harder to detect and potentially a lot more dangerous.
I'll give just one, one I think here example. Microsoft was under review from CSA because of an identity related breach where the State Department was compromised. What I think was interesting there was that the way that breach was discovered was through a detection rule for e-mail security that the State Department had internally.
It wasn't. It wasn't until then that Microsoft realized that they had lost a key, like a private key that the attacker was using to sign requests to expiratory data. So that really speaks to the complexity of these breaches and the lack of detection capabilities that we currently have. Yeah, it's pretty amazing. That's a great story that you
shared. You know, I kind of wonder about that scenario because you hear about it all the time that breaches aren't detected for 170 days, something like that, that kind of dwell time. And I always kind of wondered what drives that from the adversary's perspective. They want to get in, obviously, but why does it take so long for them to be detected? Because I'm assuming the detection really is winds up occurring where they detonate whatever the full blown attack is.
So is it like in the meantime they're doing research or they get in so many doors that they can't conduct the attack on all them? They say, all right, we're, we've got a backlog of work here in our in our hacker, you know, project plan. And so four months from now, we're going to go get that cup to have in your experience. Why? Why are those well time so long? So, so you have different classes of of attackers.
You have some attackers that are financially motivated and then you have attackers that are more politically motivated or have espionage in mind. For the second class of the attackers, maintaining access to the system is by far one of the key statement in their mission. Like they need to stay in that system once they've compromised. So what they do is everything in their power to stay stealth and under the radar and not trigger
any detection. Whereas for financially motivated attackers, they are more interested in sort of like the equivalent of a smash and grab where like they install ransomware and similar. And for them, what they try to do is find a way to that, to get to kind of like your most sensitive data and then either exportrate that data or use ransomware to, to, to force you to, to pay up or similar. And so in those cases, they care a bit less about detection.
And, and so the detection time, the detection time frame is, is a lot shorter before espionage and positive motivated attackers. It is part of their MO to stay as stealth as possible, even though that might mean that it'll take them longer to accentuate data and what not. OK, I'm that makes sense. So, So what does slash ID do given all those different scenarios? What, what are the things that you're detecting that if I'm an I am practitioner, I'm going to miss today.
What, what is it? What's that special trigger or multiple triggers that slash ID is doing for me? That's going to say, OK, now I see why I spend the money and invest in that. Yes. So we do three things on the detection side. One is we can monitor our privilege identity.
So you can map, you can mark an identity as privileged and any change done to that identity with respect to creation of credentials, changes in the policies that they have access to, entitlements access and so on, we monitor and alert you on that. So you are always aware of whether one of your crown rules is being is being used without sort of like a proper reason in place. The second thing is we alert you to any behavioral pattern that we see in an identity that hasn't been seen before.
So it follows this item. We see a service account that is trying to connect to a machine that has never used in the past 90 days or 180 days. You get a detection that that you can action on either we'll get to the remediation in a second, but either manually or automatically through our remediations. And 3rd, we're we're able to help you detect life cycle issues.
For instance, we're able to detect identities that haven't been off border properly, orphan credentials, roles and groups that haven't been used in a long time, and this helps minimizing the amount of pivot points that an attacker can have when they're trying to move laterally in your environment. Yeah, that, that's fantastic. So that's how I detect it. And how do I go about remeding it? And I guess there's two concerts they have.
So if somebody, if I'm detecting OK, somebody's gotten in, somebody's on the network they've had, they have some accounts. How do I trace back? Is this combination tools? Is there a role that slash ID plays in this or trace back what maybe they've done over time? Because I guess there's 2 scenarios. 1 is I bring slash ID to and I look at my current environment.
But then there's the going forward of how do I make sure that I detect the breaches quickly so there's not someone sitting on my network for a year. But if I bring in slash ID and I have been breach, but maybe that breach hasn't resulted in the big data exfiltration or ransomware insertion or something like that. Maybe the, the, the hackers in the process of trying to escalate privileges, things like that. How would I know what they've done?
Have they created accounts and things like that? And then what do you think is the the process for cleaning up after that? Yeah. So what we do is we record by looking at log data. We record the actions of every identity so that the moment a detection triggers, you're able to look. Back. In time and see everything that that led to that to, to, to the potential breach and attack.
So it's easy both for the identity team and the SoC team to understand what exactly happened in your environment that led to that specific problem. When it comes to remediation, we provide three ways to go about remediation. 1 is remediation playbooks. These are instructions that your IAM analyst or SoC analyst can manually follow to remediate a specific finding, whether this is a posture issue or an active threat.
The second option is fully automated, so you can use our AP is to automatically remediate on a detection where it triggers. The advantage of doing that is you stop the attacker on their track immediately. Like we invalidate tokens, access tokens, so they can't move anywhere, you remove all the privilege, all the entitlements from a role, so they can't use the role to do anything in your system and so on. But some companies are are concerned about doing full remediation.
So we provide 1/3 path, which is the ability to remediate in conjunction with a sort tool or or or manually through our UI, where you can go in, do your investigation, and then decide whether to suspend an entity, rotate a secret, quarantine a role, and so on through our UI or through the sort tool that
you normally use. Is there a way to also automate that, so if somebody comes in and detects something to, hey, take, you know, predictive action to say, temporarily suspend this account until further research is done? Yeah. So. So what what you can do is, is when a detection triggers, you can have actions like suspend a user or a role or or a credential. And then once the investigation is done, you can decide whether to restore that identity or keep it, keep it blocked or delete it.
So one more question, So you mentioned logs. So is this something that works in concert if I have a SIM solution on my network or does it have to replace my SIM solution? So does could it work with Splunk or no? Just throwing that out there, Splunk. Or do I have to now send my logs
TO/ID? So we work with your existing SIM and we can send our detections and alerts to your SIM so that your SoC team doesn't have to use a different UI that they're not used to. And we, we, in general, we, we try to make sure that whatever tooling you already have, this is true both on the IGA side and the SoC side, We're able to integrate with them so that you're not changing the UI flows that you're used to. And so we can dump all of our
findings into your SIM and then the SoC team can use the same to investigate similarly because we expose everything through AP is you don't if you don't want to. You don't actually have to use our UI at all. You can have your Terraform infrastructure as code. Use our AP is to pull information or remediate specific actions. I mean, to me this is like ITDR the vision realize, right?
It's all about having visibility to your environment and detecting the threats, but working with your existing infrastructure but adding the identity intelligence on top of that is kind of that's kind of the approach that you had in mind. Yes, yes. What what we really tried to do is augment your existing tooling. We're not trying to displace your IGA program. We're trying to make it better with that intelligence layer there often often is missing.
So if I have all this information right, I guess I can think about if this is from a measurement standpoint. All right, I just invested in slash ID. What do your typical customers say is like, OK, this is how we measure the success of the of the platform because it's almost kind of like you hope you don't have to use it, right. But you end up hopefully with, you know, data that can kind of come through and say, OK, we're detecting these things.
And what do I do from like a response perspective? What if you found is sort of like the the key justification that your customers have said, OK, yeah, this is This is why we bought it. Yeah. So we find 3 things that customer mentioned to US. One is reduce time in IGA tasks. This is both in terms of like roll out or IGA programs as well as just the time it takes to do access reviews and access request thanks to the intelligence layer that we provide.
The second is the reduced timing investigation. When there is a potential breach finding who actually created an identity, was that an identity stale? Is this a false positive or a false negative that saves a hundreds of hours for both IAM teams and sub teams? And then lastly, the the, the, the ability to use our remediations to avoid all the manual effort that analysts have
to do today. Where consider you need to go to the platform team and ask them to write some terraform to fix identities or your IMIM team has to go in and manually fix stuff. Whereas you can use as as a sort of like an obstruction layer to do all the remediation. Ultimately I think that what this boils down to is 1 it's much easier for you to be compliant and prove to your auditors that you are compliant.
And then two, you have the Peace of Mind that you don't have to to spend time building like custom detections in your in your sock team to detect that entity based attacks. That rule set is already built into the product with some sort of standard capabilities, but I imagine is is if me as a customer I can add additional policies or rule sets to detect
against too, right? Yeah. And as I mentioned, you can monitor highly privileged identities that are really important to you and might not have sort of like might not have been picked up by our out-of-the-box detections. How would I go about setting that up? Is it as simple as coming up with like a naming rule or maybe a group membership? Or do I go in and flag individual accounts? I'm just trying to think of ways like, all right, in the real
world, right? You know, I've got an Active Directory account and then I have like an Active Directory account dot Adm, right? And companies tend to follow patterns. Can I do some sort of like pattern matching or group membership analysis to say OK anytime an account like this shows up, I don't have to remember to put it into this bucket, it will just automatically go into that bucket?
Yes, So you can, you can do group relationship analysis to automatically tag certain certain identities. You can also use our AP is as part of sort of your life cycle processes to mark specific identities as a privileged. And then lastly, we do analysis on our side based on the type of permissions and the type of access that the an entity has to say Pai information and so on to mark certain identities as high risk so that you have that full coverage.
OK, so I'm sold. I'm going to get it and I want to deploy it. What does it look like to set this up? I guess how long does it take for me to, you know, get, you know, it's, it's probably an ongoing thing, right? Identities are forever and there's always something new coming in. But what's a reasonable expectation say, OK, I've got this thing set up and now I've got some actionable data to do things with. Is it days, weeks, months?
And the curveball in there is how long do you think is appropriate to detect what I would call, you know, abnormal behaviour? Is it based on the account the person, right? There's, there's always that kind of tuning period, right? So, OK, well, what is normal for Jeff? Well, Jeff's never normal. So he doesn't fit into a bucket right? Yeah. So I think one of those things that we do uniquely is we're able to ingest historical data that you already have in your environment.
So a lot of companies have data in their SIM in S3 and so on. We can ingest that data the moment you connect to us. And so you can get behavioral information out-of-the-box immediately, within 24 hours from when you connect to the environment. The setup itself takes less than 15 minutes. You give us credentials for your environment and we provision it automatically if it's a cloud
based solution. If it's on Prem, you deploy our collector which is a docker image and the collector starts to stream data to us. OK. So is this something that you can maybe walk us through and kind of show this how this works? Yeah, absolutely. I think forgiven that this is a podcast, I'll try to keep this as brief as possible and not particularly in in try not to bore people.
But basically once you connect to the to the environment, this is the typical, typical view you would have for an identity. As you can see here, this is a AWS role. It's it's an NHI. We tell you automatically you created the role, but I mentioned earlier that we use LLMS to improve kind of like the the readability of this data and
the visibility. So you can see here that our LLM can automatically generate a description for this role to tell you exactly what the role does and can do in your environment. So for our. People who are listening, I guess I'm looking at like this dashboard, right? And it's it's essentially pulling in AWS information and then and then you're doing
things against that, right? You mentioned the LLM and coming up with, you know, probably more human friendly descriptions of what things happening on, you know, going into this interface. And then so OK, I have a bunch of triggers and configures that I can do right? Yep, Yeah, exactly. And I mean if you if you take sort of like this, this role here, like the role doesn't tell us that much. It's called AWS service role for Amazon, even bridge API destinations. That's not like super helpful.
Having a human readable description of what this thing can actually do is already quite helpful. As I mentioned, you can suspend this role, delete this role. You can do a bunch of actions on the role and we discussed a bit about like the the ability to help IGA processes when it comes to reducing excessive permissions. You can see here that we can look back in the log data and see which permissions haven't been used by this role in some period of time where it's configurable.
And then you can ask our LLM to generate a appropriate policy that we actually verify in the environment to make sure that we're not accidentally sort of like removing privileges. So here you see a full blown AWS policy that is tailored to this role and achieves least privilege based on the past seven days of data. So that's one you there's like functionality from like a Kim system or CIE cloud infrastructure entitlement management.
So the the the core difference here is that most of the Kim systems try to tell you what entitlements haven't been used, but they don't help you with remediation. Can you do the same thing from other cloud platforms like Google Cloud as well as Microsoft Azure? Yes, that's the other powerful, that's the other big differentiator. We can do it across all the providers that we support. It's not just AWS specific. And so you have the same least privilege capabilities across
all the environments. So you click this button that said get recommendation and then that's where the LLM is chunking through the data and saying OK, well what should we do about that? I guess explain me more what that get recommendation button did on the screen. Yeah. What that does is it looks at the historical data, it looks at the existing entitlements for
that identity. It removes all the entitlements that have not been used in the the period of time you selected, which can be one day, seven days up to like 90 days. And what we then do is verify that policy before showing that to you because obviously, as you know, LLMS can hallucinate. And so we want to make sure that the policy is actually well formed and is not accidentally breaking anything in your.
Environment and then basically what you see is like this essentially like a script, right? Like here's what we're going to do and then I take that information, then I can either run it individually or can I click another button that says, OK, do that. How would you automate that part of it? So what you can do is to use use our APIs to automatically deploy this across across your environments.
I mean, one thing that occurs to me is that this gets you a good way toward your lease privilege policy. Didn't get you all the way there, but lease privilege is so hard to achieve that if you can at least start to clean up unused roles, roles that you're not even using, that shouldn't exist in the environment, and this takes you a step closer to
that. Yeah. And the way we think about it from a, from a security standpoint is what we're doing here is really reducing the options for our attacker to move laterally in your environment. They might still breach an identity, but then they won't have the same degree of entitlements that they would have otherwise. And so we get to as close as possible to less privilege, while while at the same time sort of like being easy, easy to use. It's not as as big of a lift as something like IGA.
One thought I had about this is, yeah, the the lateral movements, absolutely. What I would love to see, so you have my Christmas wish list, would be take this functionality and bring it to the on Prem environment. If we could do this for the on Prem environment that would be a dream come true. Yeah. So the the good news is that we can already do it for AD. So we support. We support AD as well. There you go. That's huge. That's very cool. So I know it's a little bit of a
visual demo. So for people who wanted to follow along, we'll have it up on our YouTube channel. Come and check that out. But definitely appreciate you taking the time with us. Vincenzo, I want to ask you a question before you wrap things up. We, we try to end things on a lighter note and I don't know how light this will get, but I'm sure you've seen some strange, unique, scary, baffling things maybe over your your time with maybe things like Blackhat and so forth.
What is the most memorable thing that you've maybe seen as as part of, you know, that environment or maybe you know that that culture of of attackers and defenders?
Yeah, so the, the there are a lot of like interesting stories that I'm not sure I can talk about, but but I'll, I'll say one that is dear to my heart because because it was part of it. So at the beginning of my career, I start to participate in this competition called .1 where you need to demonstrate a live exploits against either a
mobile phone or browser. And the way this works is you fly to Vancouver, you have this like 2 days competition live where like you run your exploit against the device and hopefully it works and, and, and you win. What happened to us one year was the vulnerability got patched literally the night before of the competition. And so we had to stay up like 48 hours straight to find another vulnerability, rewrite the
exploit and try to try to win. It was, it was a very, it was a very fun experience for us. But I think he also speaks to sort of like the, the, the, the complexity of like this world and how hard it is to like keep up with attackers. Yeah, it's always that cat and mouse game, right? But I, I don't, I good on them for patching it and then good on you, I guess fighting and something else that you could get in through, you know, in a relatively short order.
So I guess that just highlights, right, the speed for the detection is such an important part of this is, OK, well, how quickly can we detect something, right? That dual time is so important and it becomes more important as we become more automated and more, you know, let's say bot and AI driven where these things are happening, you know, very, very quickly, millisecond speed. And so it can be very difficult to kind of detect all that was. Is that a fair assessment?
Yes, I like on on on that front. One thing that I think flew under the radar a bit too much, but recently the Microsoft Research team used an LLM to find vulnerabilities in bunch of book loaders. The scary thought is we might be getting to a point where finding vulnerabilities is actually very quick, very fast. And so attackers will have two
levers that they can use. On the one hand, it's much easier to fish people because I get fishing these days is is almost impossible to to to tell apart. And then on the other hand, the factor that you use to compromise is now much easier to to deploy because it's easier to find vulnerabilities. So I think LMS on the offensive side are somewhat scary just for the the increasing pace and making it hard to detect. Yeah.
I mean, gone are the poorly written emails and text messages, Yeah, with second language. And now it's, yeah, like I said, very, very difficult to detect. And it's going to happen at some point. So you know what, the AIS fight each other and then just let me know who wins sort of at the end. Definitely appreciate you taking time with us. Vincenzo, is there anything that you'd like to get out for people that we haven't covered yet that the people should know about
Slash ID? No, I think, I think we we covered everything. I will say maybe one last thing, which is Jim mentioned that achieving these privileges is very hard. One of our maybe contrarian beliefs is that achieving these privileges is impossible, which is the reason why you need detection and response capabilities because you'll never be at a place where everything is perfect. Everything is properly segmented
from under 19 standpoint. And so you need to have the ability to detect and response and respond to attacks. I, I can, I can, I can definitely agree with that. I think, you know, perfection is very difficult to achieve. So you need something to detect the stuff. So I'm on board with that one for sure. So we'll point people to the website slashid.com/IDAC.
We'll have that in our show notes as well as your LinkedIn profile if people want to reach out, have questions, you know, maybe share a, a Black Hat war story or two, whatever that might look like. So definitely, again, appreciate you taking time with us and thanks everybody for watching and or listening. So you can find us on the web, IDC, podcast.com and yeah, we'll talk with everyone and the next one. Thank you both. You've been listening to Identity at the Center.
We hope you've enjoyed the show. Make sure to like, rate and review, and we'll be back soon. But in the meantime, hit the website at identity@thecenter.com. See you next time on Identity at the Center.