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.