The right way to look at this problem is that identity is a
data problem. What I mean by that is because
we have so much fragmented data, there is so much context out
there. If you can put all of that
together in a single data lake. And that's what Andromeda does,
ingest all data from all the data sources, IDPHR systems,
cloud providers, most importantly activity logs.
And then once you have everything in a single space,
you can run models on top of it. So we done machine learning
models around risk scoring or behavioural analysis, peer
behaviour, your past behaviour and so on.
And then all the use cases really come out of that data and
the models. So what does Andromeda do?
Well to start with, it gives you visibility.
So it discovers all identities, human and non human, and builds
a risk model, a score across posture, behavior and
permissions and tells you which identities to focus on, which
are your high risk identities, and gives you built in
remediation steps. 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 Steadman.
Welcome to the Identity at the Center podcast.
I'm Jeff, and that's Jim. Hey, Jim.
Hey, Jeff, how are you? Not so bad yourself.
Happy 2025 is our first Sponsor Spotlight episodes of of the
year. It is, and we're starting off
with a bang. Like you mentioned, this is a
sponsored episode, so we're very fortunate to have one of the key
members of the Andromeda Security team here with us.
They are. So it's Andromeda Security.
You saw that in title as we were as we're rolling this out.
They're an AI powered identity security platform.
You can find out more about them at andromedasecurity.com/idac.
And I mentioned it, we've got one of the Co founders here, Co
founder and chief product officer of Andromeda, Ashish
Shah. Welcome to the show, Ashish.
Thanks, Jeff and Jim, really excited to be participating in
that. Thank you.
Well, thanks for joining us. We definitely appreciate it.
You know, we have a lot of stuff going on in the identity space
and I always love to hear origin stories of where did people come
from when it comes to their digital identity journey.
So why don't you tell us about yourself?
How did you get into the digital identity or IM space?
Is it something that you chose or did it choose you?
Great question. So most of the founding team at
Andromeda came from a company called Avi Networks.
Avi was a software load balancer web application firewall company
founded in 2013, acquired by VM Red in 2019.
And we saw the journey of our customers at Avi into cloud and
SAS and we saw identity, especially permissions
management was a key problem that our customers were facing
as they moved to cloud. It's very different than what's
on Prem versus cloud. So that's where the the genesis
of the company started. And then as we started looking
into the problem space, we saw that a lot of unsolved problems
out there. There are lots of vendors there
of course, but there are lots of problems out there that are
unsolved. And so if you just when we
started and Ramadan, we started looking at, OK, what are the top
challenges that we have to that are still unsolved.
I think the biggest one that I think all we know about is
identity is at the center of attack, no pun intended, but
it's it's a primary attack vector today.
It's not if it's when it'll get compromised.
And so the attack surface really is determined by the over
privileges of the permissions that any identity has, human and
non human. So that was the biggest problem
we want to solve this. Can we get to a state where even
if you have a compromise that is 0 or minimal business impact?
So that was the first problem we wanted to solve.
But there are other day-to-day problems such as even today, the
access management is manual. When somebody joins or leaves or
moves, the manual work flows and and especially in cloud, people
don't have patience to wait for hours to get that accesses
compliance is a pain today. Frankly, there's a lot of rubber
stamping going on. And all of these issues are
relevant for both human and non human identity.
And I'll just leave with one last thing, which is NHI, a non
human identity has a additional unique problem, especially with
the automation and and and and adoption of cloud and DevOps is
discovery what's out there. So this was the kind of the
landscape with which we saw that.
We realized that this is a problem space that we can, it's
a hard problem space, but it's a problem space that we can add
value to and differentiate. And so that's where we started
Andromeda. Give me some ideas of what the
Andromeda platform does, because I'm sure there's a lot of
different problem solved. You mentioned NHI or non human
identities. You mentioned the human aspect
of things like rubber stamping when it comes to, you know,
compliance and access reviews and everyone's favorite, you
know, IGA activities and things like that.
Tell me a lot about the platform.
I know we're going to dig a little bit more detail, but give
me just kind of a quick high level to to whet my appetite.
Sure, sure. So if you want to see a tagline
Andromeda as an identity security platform for both human
and non human identities, right? And the the ultimate goal is
that we automate your permissions and life cycles of
human and non human based on risk context and behavioral
analysis so that even if your identity is compromised, that is
minimal to 0 business impact, right?
That's what we started with. But but what does that mean?
So before I answer the questions, what Andromeda does
in detail, let let's understand why it's broken today.
So if you look at the the vendor landscape today, they're very
fragmented. They're NHI only vendors.
And then there are even within human identities, you hear the
buzzwords ITDR or ISPN or Kim Jit and IGAI think the right way
to look at this problem is that identity is a data problem.
What I mean by that is because you have so much fragmented
data, there is so much context out there.
If you can put all of that together in a single data lake.
And that's what Andromeda does, ingest all data from all the
data sources, IDPHR systems, cloud providers, most
importantly activity logs. And then once you have
everything in a single space, you can run models on top of it.
So we done machine learning models around risk scoring or
behavioral analysis, peer behavior, your past behavior and
so on. And then all the use cases
really come out of that data and the models.
So what does Andromeda do? Well to start with, it gives you
visibility. So it discovers all identities,
human and non human, and builds a risk model, A score across
posture, behavior and permissions and tells you which
identities to focus on, which are your high risk identities
and gives you built in remediation steps.
So that's step one. Think of it as a journey of your
identity security maturity to start with visibility,
recommendations, remediations. The next thing we do is real
time visibility into who has access to what roles and
permissions and more importantly who's using what so that you can
right size the roles based on not just usage, but more
importantly risk. Because our theory is that only
frequently used permissions that are low risk should be part of
somebody standing privilege. Everything else moves to just in
time access. So the least privilege is the
second set of use cases that we do that moves us to just in time
access. There are lots of JIT vendors
out there. The way we differentiate in JIT
is use context. Use behavioral analysis.
If Jim requests a privilege role and if he's always done it, same
location, same devices, why ask Jeff?
Who's going to rubber stamp it anyways?
Automatically approve it, take the human out of the loop and
the risk is low. But if Jeff is asking for this
for the first time or is in a different location, then add
friction, ask Jeff and tell Jeff what to look for so you can make
a more informed decision. That's how we do intelligent
jet. And then the final piece is IGA
user access reviews based on activities, past behavior and
life cycle management of identity.
So it's a platform and we can go into the each of these in
detail, but hopefully that gives you an idea on what we do.
I think it's helpful because it, it really kind of, I guess it
spans the Galaxy, pardon the pun on that.
You know, there's this this concept of being data-driven for
an IAM program. When I say program, I mean the,
the way the program itself operates, the people, the
process, the governance, etcetera.
A lot of organizations are sitting on a treasure trove of
data that sits in a system and really never gets used for
anything beyond, oh, great, we got a new onboarder, a new
joiner, a new believer, things like that.
I feel like there's so much more that could be done with that
data, especially if you're able to contextualize it, bring it
into the system and then combine it with automation and say, oh,
OK, because X, here's what's going to happen.
Why, right? And or else Z, right, Whatever
that looks, you know what that pseudo logic looks like.
So I love this idea of it. I want to let Jim ask some
questions instead of me hogging all the time.
But I've got one last question before I turn it over to Jim.
How do people measure success with Andromeda?
Because it feels like there's a lot of different ways it could
be done, but I'd love to hear straight from from you.
Excellent question. So customers buy a solution to
solve a problem, they don't buy a platform, right?
We have a platform doesn't mean we sell a platform, right?
We sell use cases. So we meet our customers in
whichever step of their journey they are in, right.
So we have customers who are in the early stage of the journey
where well I don't have visibility into how many
identities are there and who are the risky ones especially than
NHI side, right. And the other extreme of the
maturity curve is, well, I am implementing JET.
I need something that is automated based on intelligence
and context and everything in between, from role right sizing
to least privilege or access reviews and so on.
So we meet our customers based on the current pain points, help
them solve those pain points better than anybody else.
And once that's done, then expand into a second use case
and 3rd use case. So success is frankly measured
by, well, what is the current problem statement that you're
trying to solve? How can we help you do that?
Let's take an example for just in time access.
Well, there's a customer who's do decided to deploy Jet and
they look at multiple vendors and decide an Andromeda.
So let's operationalize that in a phased manner.
Let's make sure Jet is deployed. Once that hits a certain
maturity curve, let's look at let's for example NHI use case
and so on. And we have a different customer
who says I'll get to JET in future.
I want to first solve my NHI use case.
Let's start there, right and then go on.
So that's how we we measure success based on the specific
use case the customers wants to deploy in and then land and
expand. So Ashish, you are were
tremendously popular. You're boothless popular at
ideniverse at Gardner, which was the most recent one we saw.
You and Jeff and I are regulars at this conferences every year.
You're hard to get much more than a handshake from, but you
had a lot of people. We wanted to hear your story,
understand what is it that you guys bring to the table.
Here's my perspective is that as customers, we want to put
everyone in a box. It's a, you know, we want to be
able to relate that to something we understand.
And when we have budget line items as practitioners, we have
a budget for IGA replacement or IDP replacement.
Where is it? Does Andromeda fit?
What's the closest bucket? Is it IGA is a privileged access
management? Is it ITDR Keem, you tell me,
you know, if somebody's going out and saying I got money for
IGA, is the Andromeda on that list?
Great. Question Jim and I, I understand
totally how we all like to bucket solutions, right?
Because it simplifies how we think about it, right?
Because there's so many vendors out there and you need a
structured way to bucket these and say, OK, this is this
category and this is that category.
So it's a fair question. We like to flip the question
slightly and say, OK, what is the current problem you're
trying to solve? OK, you're trying to solve an
IGA problem. Does Andromeda have a solution
in IGA? Yes, it does.
You are trying to solve a JIT use case.
So I'm looking for a JIT vendor. Does Andromeda fit into that
category? The answer is yes and so on.
So rather than putting Andromeda in one bucket, we like to think
that we had a platform that spans multiple use cases across
multiple of these buckets. And depending on what is the
current pin point, as I mentioned earlier, we would be
able to, if you're able to address that, then the customers
would would buy that. So, so that's why we look at it.
The, the reason this is an important distinction is that
because because of these bucketed vendors, we have this
fragmented landscape and we think that the right way to do
that is put everything in a single data lake and build
models on that. Let me give you a specific
example. One of the most common thing
today you see is lots of NHI vendors, which is great.
And I'm sure we'll, we'll talk more about NHI later on this
podcast. But our contention is that NHI
itself cannot be solved in isolation.
I'll give you 2 reasons. The risks of Nhis and the
corresponding human users are intertwined and the life cycles
are intertwined. If I left the organization, all
the Nhis that I managed or owned or used have to be the deleted
if they're no longer in use or re keyed and reassigned to
somebody else. Otherwise there is a Latin risk
of that NHI by the by the now exited employee.
So the life cycles and intertwine same thing around the
the risk right and a risk of a human user is not just
identified by the rules and the access to the application that
he or she has, but also the relevant roles and permissions
all the Nhis that he or she is managing right.
And finally, I would say that other than the discovery
component of NHI, which is unique because human identities
have a directory service and HR systems, Nhis don't.
Other than that, the permissions management, the governance, the
privilege access management are common to both human and non
human. So why have separated solutions
when you're trying to solve the same kind of problems?
So, so that's, that's why we don't like to bucket ourselves
that we are IGA or PIM or Pam or or Kim or so on.
We like to say, what is the use case you're trying to solve?
Let me let us show you whether we can address that better than
anybody else. And then if so, you can use
Andromeda. OK, that's a really cool
perspective. So let me ask the question then,
what is the ideal customer type? Because I work with some clients
who were mature or were very mature at one time and they kind
of reached some of the sticking points with the technology
solutions they have. They can't take on some of these
newer use cases that are presented from cloud
environments or maybe their scale has grown.
I also work with clients who, you know, they've really just
haven't invested in IM in the past decade.
And so they're more or less a Greenfield.
Even if they have an IGA solution, it might not be one
that, you know, people commonly talk about it anymore, might be
that old, right. So what is the ideal client who
comes to? Is it the the savvy client or
the client who's just getting their feet wet?
Or maybe it's a savvy practitioner who took a job and
it's, like I said, Greenfield. Yeah.
That's a great question. So I'll, I'll answer it with two
perspectives. What is an ultimate vision?
But as a start up, what is their current focus, right?
Because the end of the day, it's a matter of physics, right?
So as a start up to be successful, you have to make
sure that you are addressing the use cases in the right order and
not trying to boil the ocean. So let's start with the with,
with what, what, what we support today and what our ideal
customer today looks like our ideal customer today is anybody
who's trying to solve an identity security problem for
cloud and SAS. And whether and in each of the
buckets that we talked about, whether it's around visibility
and risk scoring of your identities, human or non human,
it's around least privilege, it's around just in time access
in cloud or IGA for cloud and SAS.
So in any of these buckets, if you're focused on your cloud and
SAS environment, that's our ideal customer today.
We do not have an on Prem solution today and so that's
that's the current focus. But segwaying into where we are
going, well absolutely we will scale into on premises as well
and that's a longer term story as we matured our product, our
integrations and so on. And so our vision is to be able
to be the identity security platform across human and non
human based on risk and context and behavioral analysis across
all of the use case. We talked about cloud SAS on
Prem today it's cloud and SAS you.
Mentioned non human identities said maybe we'll get it.
Yeah, we're definitely going to get to that.
Your website screams human and non human, but I would say 2024
was the year that we woke up and said, oh, if these non human
identities, they're a problem that we should deal with.
I've been an identity for over 20 years.
It's been there the whole time. The problem has been there.
But now everybody's talking about it.
Maybe 2025 is going to be the year that you know, you know,
all heck breaks loose. But my question to you, Ashish,
is why now? Why is it that everyone's waking
up to this problem now? It's, it's a great question.
You're right. I think my thesis there is that
we hit that, that maturity curve, we hit that inflection
point off NHI usage. So if you think about it, Nhi's
were there. It's not that the machine
identities or Nhi's were not there on premises, right?
It's that the cloud and SAS has increased the a use of
automation, DevOps and that has proliferated the use of Nhis.
And I think we try to bucket ourselves or we try to bucket
Nhis into all Nhis are equal. They are not that different
kinds of Nhis from service accounts to API keys, tokens to
even AD credentials used for on premises, right.
So I think. That's a podcast on Albert's
own. We just said that, right?
Yes, that's right. That's right.
But the reason I think the NHIS has taken up is because I think
we've hit that inflection point where the adoption of dev OPS in
cloud and automation has gone to a point where it's become a
serious problem. And the one of the biggest
challenges with NHIS that I think we referenced earlier is
there is no single source of truth that is not directly
service or an IDP equivalent for NHIS.
And so I think it's even a harder problem because you can't
gate all Nhis through a single funnel like we could do through
SSO and MFA for human users and look at HR as a single source of
truth. So I think that's the reason why
all of these things coming together, we are seeing a lot of
focus on NHI, yeah. And you know, I feel like we are
now experts in managing it's human identity, right?
I mean, it's, it's kind of boiled down to it's simple,
Simon, there's some authoritative stores, normally
the HR system for who works here, maybe there's a contractor
database. And then we have a IGA system
and this fits out Access. It's really these MH is that
they're hard to manage and with kind of what you were describing
earlier, sounds like you went right after the probably you
took on the hard stuff. What makes this so hard to to
manage these? Yeah.
I'll answer the questions, but I would also contend to your point
that HI is a solved problem, but human identity is a solved
problem. I don't think so.
It's not a solved problem because it's all manual and not
really based on context. I think the Igas today are just
mostly rubber stamps. They all the roles are over
provision, like 95% of roles are over provision even for human
users. So I don't think it's a solved
problem. But let's let's let's part that
for a second. Let's come back to an NHI
question, which is what makes the NHI hard.
So let's start with what are the aspects of NHS security that are
relevant? I think we all focus on the
first one, which is discovery, credentials management, life
cycle management. I like to put all that under the
authentication, roughly authentication bucket, which is
OK, what are all the Nhis? So do discovery because there is
no central place. What are the key rotation or
credential rotation hygiene? How often should we rotate them
and how should we cycle them? When somebody with the NHI is
deleted or, or the passwords are rotated or keys are rotated and
so on? That's what most of the vendors
are focused on. It's an important problem, but
that's not the only problem. There are two other aspects of
Nhis that are often overlooked. The the the the next one being
the permissions management. They're all right sizing because
just like human users, NHI has a role and a set of permissions
and if they're over privileged you have a large attack surface.
In fact, I would argue that there are types of NH is where
key management is irrelevant. I'll give an example.
Think of AWS EC2A. VMAVM has an inherent EC2
instance profile. It's a temporary credential that
AWS manages on your behalf. You as an enterprise don't have
to worry about key rotations for these kind of workload
identities. However, you absolutely have to
worry about the roles it's assigned.
Because if that VM is compromised, the attacker can
assume the role that that workload identity is able to
take, and if it has additional excessive privileges, all hell
can break loose. So the permissions, the role
rightsizing parts of NHI is equally important, in some cases
more important than the credential piece for some kinds
of identities. That's what makes it hard.
The four and final piece I will talk about a third type of
security is securing the client. Let me give you an example.
Let's say you have, let's focus on AWS.
You have a role in my, I'm an enterprise in my enterprise
account, I have an AWS role. I'm trusted a third party, it's
a another SAS service, their AWS role in their account and
there's a client applications that using the role to access my
my, my enterprise role. There is no credential exchange
here. It's a role to role trust.
What should you protect? Two things, the permissions in
the role so that there is Nexus, a privilege and the client
application, the third party applications which is using the
role, so protecting the client itself.
We often overlook this component, this part of NHS
security as well. So I think we're still in our
early phases of NHS security. There are multiple aspects, we
all focus on one, but there are many things, many hidden
dimensions to NHS security and that's what makes it hard, good.
Answer and I want to come back for the follow up on #2 but this
was a triggered question so bonus question.
I asked this one a lot Jeff and I don't agree on the answer.
Is there a nuance between non human identity and non human
account or do they basically mean the same thing it?
Is a tricky question because account word is so overloaded
right? And AWS account is an Azure
subscription is AGCP project right where the traditional
account means an identity. So we we think of account and
identity almost synonymously because the way to think about
it is that it doesn't have a set of permissions roles, which
allows it to do something. Then you need to worry about as
an identity. And and I think, I think, I
think if you if you apply those first principles, then you can
think that NHI and the non human account are are equivalent.
I was. Kind of thinking of the term
account in terms of, you know, the kind of the traditional
sense of they username and password kind of thing.
Not so much the AWS account, but I, I kind of feel like there's a
future and I don't want to think it's too far off track.
A future where you have AI worker robots and they can make
security decisions on what they're not account or, you
know, accounts. I'm called using the term
accounts again should have the permissions that they have.
I can basically make decisions like people.
So that is a an area where a non human to me would be an
identity. I digress.
Well, but I, I want to get to this because you, because we
definitely don't agree on this one.
And that's fine, right? We're, we're exchanging ideas
here. Where does account stop and
identity begin and vice versa? I think that's really kind of
the crux of the question is you have an identity.
I have an identity. We also have accounts.
Can a non human also have an identity because it also has
accounts or maybe it's its own entity, right?
Or whatever we want to call it. You know, Jim, in your example,
a worker bot, right? Or AI bot or chat bot or
whatever it may be. There's going to come to the
point where you're going to effectively hire AI workers to
do things. Do they, do they have their own
identity because they have account?
I don't know, right? I think that it's, it's an
interesting discussion in my mind because it's very semantic
and almost kind of like, you know, philosophical.
So so we have a perspective one I was.
Just going to say, I think we should have an episode and tap
into smart people like Ashish to answer that question in under 3
minutes. And then kind of like we did
with I Am versus digital identity, What's the difference
and make an episode out of that, yeah.
So if I may add one thing, we actually see some of the
practical implications on this even today.
So for example, I'm Ashish, but I'm logging into AWS through
SSO. OK, so that's an identity right?
But I might also have a local break class account within an
AWS account. Is it the same Ashish or is it a
different account? We, we, what we do is we put all
of that under a hierarchical umbrella.
We call it in we, we, we call it an I'm looking for the right
word here. It's an instance or it's, it's
an incarnation. So Ashish is the ultimate
identity. Ashish has multiple
incarnations. 1 is an SSO incarnation, 1 is a break class
incarnation. That helps us because you can
use the incarnation when it's makes sense.
Like who logged in, the specific incarnation logged in, Who does
it belong to? It belongs to Ashish.
So you can answer these questions depending on what
you're trying to. You can you can.
You can get to the right answers based on what you're looking
for. Similarly to AAI bot question,
the AI bot can be an NHI itself with its own incarnations, but
the ownership is Ashish's because Ashish manages it.
So you can do a combination of human and non human ownership
relationship and within the identities incarnation notion
where it's just one one identity but has multiple accounts,
multiple incarnations depending on which system it's used in.
That helps us in general, but it's a larger conversation.
It is and it I feel so, so, so semantic around this, right,
because you're right, we use accounts, we use identities, we
use IAM to mean a whole bunch of different things that probably
shouldn't. And words matter, especially
when you're talking to people and make sure you have the, you
know, you're using the same language, the same definitions
of those types of things. But I'm going to I'm going to
lay my, my, my Infinity gauntlet down here and I'm going to I'm
going to drop the mic on Jim real quick.
We don't call it non human accounts.
We we've been calling it this entire conversation, human
identities and non human identities.
So there you go, Jim. That's how that's so my my
comeback if you. Came to work at my company.
You just said man I gave you here's your login for your
e-mail, here's your login for the application 123, and here's
your login for application ABC. Would you say you have 3
identities or three accounts? I would say I have 3 accounts
that map back to my identity, my mastery record, whatever you
want to call it, Incarnation as she mentioned, like things like
that is you've got an identity, and then if you think about as a
tree underneath, if you double click an identity, you'll see
three folders for three different accounts there.
There's one Jeff Sedman and the world.
Doesn't need any more. And also, I think with with
identity, using the term identity when it comes to, you
know, hey, Terraform spins up 500 accounts a day.
It doesn't have 500 identities, doesn't create 500 Jeff
Steadman. So it creates 500, you know,
accounts that exemplify Jeff Steadman.
We're going off the deep end here and I have a better
question. I I think it's better, it's more
in target because you talked about this is a data problem.
And I totally agree, especially when it comes to authorization.
I mean, that's the the hard problem, right, is understanding
what an account or an identity has access to in total, what it
should have access to, which is usage patterns.
I mean, you think on this hard problem, talk to us about why.
I mean, to me it's like it gets down to like exactly what the
issue is. It's trying to drive toward some
some instantiation of least privilege, right 100.
Percent and and you can also call it zero trust for identity
right? What is the definition of least
privilege? What is the definition of 0
trust to us to at Andromeda? It means that any identity
should only have those set of permissions on it's standing
basis, on the standing basis that are frequently used and low
risk and why that matters that remember we said it's not if
it's when you'll get compromised.
So when you're compromised, if your tax surface is defined by
low risk permissions, then you don't have nothing to worry
about, right? And and everything else that
moves out goes to just in time access, which is again automated
based on context. But to achieve this true zero
trust or true least privilege, you have to understand two
things. You have to understand risk and
you have to understand usage. Usage is based on the actual
activity that that identity is doing, but not just that
identity, the peers. So that's where some of the
machine learning models come in. Well, if Jeff and Jim are part
of the same team, is there a peer behavioural model that can
also influence what should be part of standing privilege or
not? Because the end of the day,
remember we are trying to achieve two things at the same
time, security and agility or productivity anytime, especially
in cloud and SAS, if you slow down your developers and users,
they're not going to adopt the tool.
So we always trying to strike the balance and to do that.
Coming back to a data problem, Jim, if you can analyse the user
behaviour, the peer behaviour, the context, the locations, the
devices, the past history and then combine that with the risks
of the permissions. So each of AWSGCP Azure have
1520 thousand individual permissions.
They're not equal. There are view level permissions
and list level permissions to read, write and I am level
permissions. Can you give a different risk
levels, combine that the usage models and then derive the zero
trust or this least privilege? That's the Holy Grail and that's
what we are doing at Andromeda based on the data lake and
that's where the machine learning models, the AI models
come into play. That's why the hard problem, and
that's why it's more exciting. All right, so I smelled an AI
conversation. I knew it was coming and look,
I'm, I'm a little bit sceptical because now I start to see a
whole bunch of applications and products and vendors, you know,
jumping on AI and I guess help me understand, right.
You know, we had AI and I think of AI now as generative AI, not
machine learning, which is also AI.
Yes, but it's sort of like the what I'll call the legacy
definition, if you want to call it that.
Help me understand where does AI come into the Andromeda
platform? What is it used for?
You know, is it, is it really generative AI?
Is it ML or some mix of the two? Help frame that for me from a
contextual perspective. Definitely short answer, it's a
combination and it's not AI for the sake of AI.
It's not AI washing right. We we are genuinely trying to
figure out what is the best way to solve a problem.
So to give you an example, right, once you have all the
data in a single data like it's a graph based database, what are
the questions we're trying to answer?
So first is a risk scoring. So we have a three-part risk
model based on posture. So posture, risk configurations,
MFA, etcetera, key hygiene, behavioural risk, past activity,
behaviour, applications, logins, locations, etcetera and
privilege risk analysing the riskiness of the permissions and
the accesses and so on. So this is where as we use some
of the machine learning models to define the risk score in the
best possible way. Mathematical models, some of
their machine learning models for assigning risk score to
every role, every AWS account, every identity, every
application and so on. We also use behavioural machine
learning models for looking for anomalies, anomalies of a given
user compared to its past behaviour, anomalies of a given
user compared to its peers and so on.
And these are well defined machine learning models,
clustering models, anomaly models and so on.
We use models for so. So one place we do use
generative AI is for summarizing session activity locks.
So what we do is let's say you got a privilege sessions for two
hours. We look at the activity logs,
let's say it's AWS. We look at the cloud trade logs
of what Jim did in the two hour privilege session, every action
Jim performed and then the output of the model is an
English language. Somebody saying Jeff logged in
for two hours, he did these these, these actions, these were
anomalous, these were expected. And here is everything he did,
somethings was successful, something was not successful.
That summarization is where we use Gen.
AI models, but that's a very specific use case.
So again, it's the same data lake with the context, with the
behavior, with the activity logs.
And depending on what we're trying to do, we use different
ML and AI models. So as a as a customer, can I
tune the, you know, the models in a way to say, OK, here is
what I'm looking for or here what it here is What's risky?
I would imagine it takes time to develop whatever the access
patterns might look like, right? How do you know if something's
risky unless there is an outlier of data, right, for it to pick
up on What is, I guess one first question.
How do I tune some of these, you know, models to look for what
I'm looking for or make it more fine-tuned for my application or
whatever it may be? And then how long does it take,
you know, realistically to establish a baseline of what is
normal versus what is not normal?
Great question. Let me start with the second
question first. So when we onboard a customer,
if the customer has the last 90 days of log data, we use that
for baselining. So our, our current training
period is about is 90 days worth of data and we can always go
longer. And for most cases, customers
usually have that 90 days of data in the history.
So we can hit the ground running it with that 90 days of history
immediately, right. If the customers doesn't have
any data, then of course you have to wait for 30, sixty, 90
days for the baseline to be established.
But that's rarely happens. Now how we how we train our
models is we don't use customer data to train our models because
the good news is that especially in cloud and SAS, these are
standard applications and standard behaviour where you
know what is what is a risky behaviour of a certain certain
permissions and what is not. So we can use genetic synthetic
data to train our models. And similarly for the Gen.
AI piece where we send to to the LLM models to translate to an
English language, there is no customer data that's being sent
because. It's, it's the actions which are
generic AWS or Azure actions which are getting translated and
the context is getting translated.
Nothing that's customer specific, right.
So, so that that's a good part in terms of tuning.
There are multiple aspects of the model.
So the risk is impacted by the set of permissions as well as
the type of assets. Is it a production environment
versus a dev environment? Is it does it have PIO data or
not Those are tunable by customers today and that impacts
the risk score and so on the other aspects we will we are in
the process of exploring how we can make some of those models
more tunable, but that's again based on customers needs that
should be fairly straightforward for us to do.
Now, one of the biggest criteria for us to implement any ML or AI
model is explain ability. If we cannot explain what the
model did in an English language in a reasonable way, then we do
not want to put it in the product.
We do not want to offer that, right?
So explainability is a very, very important consideration
when we develop the product. And then finally, no models are
perfect. If we say I'm with 100%
probability, I'm telling you this is what the case is, you're
fooling yourself, you're fooling the customers.
That's not the right thing to do.
So a lot of our recommendations, lot of our summarizations and,
and, and analysis, we put up what we call it confidence
interval saying look, all confidence interval for this
analysis is 60 to 80%. Of course, if it's below a
certain threshold, we won't even show it.
But beyond certain threshold you can, you can configure and say
start showing me your recommendations and analysis as
long as this hits a certain threshold.
And then we'll show you what that threshold we have hit so
that you can tune that and say no, show me only after it's 80%
or show me anything about 50% and so on, right.
And then finally, we take input from the customer saying this is
not true, it's a false positive. So that goes back into the the
product, right? Because we're trying to strike a
balance between false positive and false negative, right?
And every customer has a different level of tolerance for
that. And that is something you can
tune and say, show me even if you're 50% confident, show me or
show me only up for 90% and so on.
And then take the feedback and tune the model again and so on.
Hope that helps. It does.
And I think 11 last question for me will be, I guess the security
of the AI models themselves. And I think you kind of
mentioned is you don't you don't put customer data right into
your model. But what are the what are the
guard lines or guard rails for? What stays, I guess on Prem or
in my specific cloud versus your cloud versus maybe a third party
cloud like an open AI or Anthropic or, you know, Google
or whatever it may be. How do you see those three
things mixing and how do you make sure that data doesn't
cross boundaries? Because I feel like that's an
area that needs to be explained. Anytime someone's saying you
know, AI, no. 100% right. So I think you, you, you, you
outline that framework very well, right.
So first of all, from the customer cloud or customer Prem,
we don't pick any data per SE. The only sensitive information
we are getting is of course user IDs and the emails because it's
it's, it's an identity product. But none of the data is pulled
into Andromeda. All of that, whatever we pull in
stays within Andromeda's cloud environment via SAS product.
And none of that goes into a third party, whether it's Open
AI or Anthropic or any any other model because what we are
sending and again, remember we're using the LLM models only
for a very specific use case, which is session summarization.
And if as a customer says, I don't want that feature, no
problem. It's it's, it's a very modular
product. So they're only the actions are
going in saying some anonymous user, user X perform these
sequence of operations, translate them to an English
language summary for me. So there is no data that's going
into a third party. But I think at a larger point,
this is a very, very important topic to us.
It's very near and dear to us because as I said earlier, if
you can't show the safety and security of our data in the
model and can't explain our our answers, then we can't build
trust in our customers, right, So, so.
Ashish, I wanted to say bravo on the explainability point.
I mean, I love that I, I've been a voice towards us for a while,
which is how can I sit in the witness chair and explain why a
decision was made if I can't explain it?
Some black box AI decided is not going to be an acceptable answer
in my opinion. So bravo on that.
You talked a lot about models and you know, I, I see this
trend that's happening in the market, which is you've got a
more savvy client. I.
Love the data lake concept. I think the client wants to have
a hand in, you know that data lake that their data, they they
want to help design it. They want to say, hey, my
business is a certain business and to us here's a certain data
element that is not important to anybody else in the world.
So you haven't figured out this use case.
This is specific to me. I want to have my product build
that into the risk score, which I'm assuming is part of a model.
So my question to you is like as a customer, do I have any
influence over how that model works or is it a black box to
me? It's a great question.
So I think the answer is in it depends.
We are, we do have certain tunable parameters that you can
influence to adjust the model. Having said that, we will be
looking in future where in your case you know as a customer
based on your data, these are the kind of models that might
make sense. And maybe you already have
developed the model and you are asking can you use this model
for me for example. That is something that we we we
were looking at potentially in the future.
The way we think about this is the following.
We cannot be the be all end all, of all the risk calculations and
all threat detection and so on. We build the product with doing
some of that on our own and ability to inject external
threat signals or external any kind of signals, risk signals
into Andromeda, right. So the product is built with
that capability. I'll give you a specific
example. Let's take an example of an EDR
and XDR solution. We're never going to be, we are
not an XDR solution, but XDR solutions have powerful signals
on devices and locations. Can that be inserted into
Andromeda? Absolutely.
That's something we'll do because the ultimate goal,
remember what is our core? Our core is permissions, right
sizing, automating permissions and life cycle, right?
So for example, if there is an external threat signal that says
this identity is compromised, we can near real time bring all its
permissions down to 0 and make all the JIT approval, the
privilege access go through multiple gates.
That is the power of Andromeda. That's the ultimate, which is
it's not if it's when you'll get compromised, but when you're
compromised, can you eliminate the attack surface as fast as
possible? Yes.
And that's where we shine and that's where we differentiate.
So I know I answered your question in in in a couple of
different ways. But to summarize, we have some
tunable parameters for risk models.
We will enable some more, but we are open to taking additional
signals, external signals into Andromeda to make more
intelligent decisions. Yes, that's the goal I love.
It I love it. I love your passion.
I think what makes identity companies go to that next level
is having somebody like yourself who's passionate and very
intelligent and a deep thinker. I wanted to ask two more
questions before we take it out. So 1, you mentioned earlier that
you set up a landing page. I'm sorry, Jeff may have
mentioned it. Andromeda security slash IDAC.
That's where people can go to get more information.
What, what will they find there? What are you going to have as
that landing page? Great question, Jim.
So it's it's an offer for a free discovery, risk coding and
permissions rightsizing. What does that mean?
We will, as part of this offer, give you full visibility, full
discovery of all your human. That's the relatively easy part.
But non human identities as well in a single dashboard give you a
three-part risk of each of those identities.
So you know which identities are high risk and why with built in
recommendations and remediation steps and right size the rolls
for you for all of those identities based on its activity
pattern and risk. That's the offer.
I love it, I love it. Final question to take you out
from the the hard part and then we'll do our lighter note.
So you're on the identity at this linear podcast and a lot of
our guests always wind up and accidentally falls out of
people's mouth, you know, because identity is at the
center. So when you first heard about
our podcast, relate that back to Andromeda security in your
platform identity of the center, what does that mean to you?
No. It's, it's very relevant.
I think I mentioned in the top of the podcast like identity is
at the center of security today because I think depending on
which you're 2320, four 2/3 to 3/4 of all attacks are related
to identity one way or the other, right.
So especially in cloud and SAS then there is no physical
perimeter. Identity is the perimeter and
your tax surfaces is the list of permissions you have.
So it's very, very relevant. So when I heard IDIC for the
first time, I said, wow, that's so true.
I, I don't think you started it when identity was the primary
attack vector, but that's where we are right now.
So we had. Plenty of foresight.
Yes, and. Luck.
Yeah, No, we knew it. Come on, Let's let's let's.
Help ourselves on ships like. We knew it was at the center.
We bought the domain name, trademarked it, copyrighted, all
that good stuff. So yes, we you're preaching to
the choir here. We feel like identity center.
That's why we named it show as it is.
All right, Jim mentioned. Like that's the hard part.
Now it's the even harder part where we talk about ending on a
lighter note, something that is, you know, maybe not identity
related or maybe it is, I guess, depending on how you look at it.
And we were kind of kind of spawn ideas for on this and I
kind of settled on this idea of books on tape.
And that's how old I am tape, right, Everything's recorded and
how etcetera. And we were kind of talking
about a couple of different sci-fi things that we were into
and stuff like that. You had a recommendation.
So I want to give you an opportunity to sell your
recommendation to everyone else, because you sold me on it.
And it's in my Audible queue waiting for me for my next
flight. And then I'm going to give a
recommendation. And then Jim's going to yell at
us, you know, from his porch, you know, saying get off my lawn
or something like that. Yeah, definitely so.
Before I give my recommendation, I think I got into listening to
books When, when I I love reading books, but I don't have
time. But when do you have time?
When you're commuting? And so that's when I got into
the books and then COVID hit. So when when we started working
from home, so I had to find time to commute.
So I can listen to the books, right?
But I got into the books a few years ago and I wanted to do
something that's not tech related at all.
Still intellectually stimulating, but nothing to do
with identity, nothing with cloud, nothing with tech.
And so I got into sci-fi and the best book I have listened to is
the Project Hail Mary by Andy Ware, same author who wrote
Martian and a couple other books as well.
But I highly recommend that book not to read, but to listen to.
Because if you see the book has not been read by, it's been
performed by, they've actually done a full production in a
studio with different accents and different dialects and
different sound effects. So highly, highly recommend
Project Hail Mary. So that's my recommendation.
You sold. Me on the performance then,
because I've listened to, you know, several audio books and
you're right, they're usually someone reading and it's usually
one person you know, and hey, more power to them.
They're trying to do different voices maybe sometimes and
things like that. It's like, OK, but you know, if
it's a full on production, sign me up.
I'm in and I'm a big sci-fi guy, so you know, this is kind of
right up my ally. I was like, all right, sheesh,
you got me downloaded. I'm in.
So I had a recommendation for you.
Now it's not produced, like you said, it is definitely someone
reading, but I think it does a good job.
And I think the story is, you know, at least from my mind,
very original at the time I read it several years back, but is
becoming, I think a little more relevant.
And it is a it is a series called, they call it Baba Verse.
And there's five different books and you can certainly listen to
them as well. We are legion.
We are many and kind of something that, you know, other
things like that. And the whole idea is basically
AI is sort of at the center of this conversation, but it's a
little more human type approach to it.
And I don't want to spoil it because they're really it really
does kind of pick up pretty quickly And then sort of like,
oh, you know, there's a lot going on here.
But I have my recommendation is Bob Averse.
It's by Dennis E Taylor, the 1st in the series is We are Legion.
It is my go to recommendation for anybody who is a sci-fi
junkie, you know, like myself. So hopefully people will check
that out. Jim, how about yourself?
Do you have any E audible, you know books on tape or you know
other recommendations? So I've had Audible accounts
over the years. I am not a sci-fi junkie and I
was reminded of that over the holiday break when I admitted to
my son that I've never seen any of the Harry Potter movies.
I don't. I'll make it a I'll admit to
I've never seen one either. And that might really, but I've
never seen one and I just don't have the interest either.
Lord of the Rings, give me, give me that.
I'm all in. But Harry Potter, not my gym.
As you could probably expect, I've never seen any of the Lord
of the Rings either. But I mean, this floored my son
and I was surprised he was a Harry Potter Potter junkie.
But you know, my, my overall recommendation is, and you've
heard me use this term a lot, Jeff, you need to sharpen the
saw. And to me, that's all about
getting outside of your normal zone.
I remember I had a, an Audible subscription to Harvard Business
Review and it's dry, it's pretty boring, but it gets you thinking
about the way the organization runs and a lot of articles on
strategy and you know, heck, now what we do is we help our
clients build their identity strategy and be able to align
that to the business strategy. I think it's so key.
So if you're not staying sharp, you're using old ideas, then
you're not going to be able to remain relevant.
You can take breaks year at a time, 2 years at a time.
You start taking five year at a time, breaks of continuing your
education, continuing to sharpen the saw.
You're going to be irrelevant very quickly.
You're. Always sharpening the saw I
need. I need a break, you know.
Here's the $1,000,000 idea is someone should write an
engaging, you know, story style approach that weaves in some of
those things. I know there was one.
I can't remember it. It's like an IT book that's
pretty famous, and it's the. Phoenix project or something
Phoenix? Project I need to see more
Phoenix Project style books where it's a story and it's, you
know, it's weaving in little parables along the way, you
know, that people can kind of get into then you sign me out
and then Ashish. We do like a full production of
it with like sound effects and, you know, different cast, voice
cast and things like that. Like I need to see more of that
in my sharpening the saw. You know, I think there's more
money in writing a book like Harry Potter.
Who? Knows, I mean, you know, you
were right. The identity at the center,
audio drama. I mean, that's what we produce
basically every week. Yeah.
All right, let's go ahead and leave it there for this week.
Ashish, thank you so much for joining us.
I'm going to have a link in our show notes for people to check
out Andromeda. It's Andromeda
security.com/idac. Take advantage of the offer that
Ashish mentioned that I think that sounds pretty awesome.
And then all the link also to your LinkedIn profile so people
can reach out if they have questions and things like that.
But thank you so much for joining us.
Any parting thoughts before we wrap this up officially?
No. Thank you for having me.
This was a fun and engaging conversation and I'm glad we are
all trying to solve the hard identity security problem in A
and and and having some fun doing that.
So Yep, looking forward to more fun coming up we.
Try to have fun, sometimes it works, sometimes it doesn't, but
we'll leave it there for this week.
Thank everybody for watching and listening.
You can find us on the web, idacpodcast.com, reach out, ask
questions, engage either on YouTube or podcast or LinkedIn
or wherever you find us. We always appreciate that.
So with that, thanks everyone again for listening or watching,
and we'll talk with you all in the next one.
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.