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.
Fantastic. I'm excited about this new
adventure or venture however you want to call it.
Maybe it's a little bit of both. I feel like the shackles are off
today, You know, what does that mean?
Do we want to talk about that? Absolutely.
Yeah. So this is sort of a new series
that we're starting. It's called Sponsor Spotlight.
Like I said, the shackles are off.
Our typical normal show is we try to be vendor neutral as much
as possible. This is not that we are
definitely going to have discussions around specific
topics, viewpoints, This is something that we've done in
collaboration with our sponsor today.
So to make it very and hopefully crystal clear, this is a fully
sponsored episode. This is what's giving us access
to have these in depth insights experts on the podcast and the
show and ask kind of direct questions directly to our
sponsor. Anything you want to add before
I introduce them? Yeah, yeah.
I think the shackles off is a good way to look at it because I
mean being vendor neutral is not always easy and there are some
areas where I wish we could kind of dive into how does your
product work. But staying true to, you know,
this is not a sponsored episode. It's not about the company that
we're talking to and you know our normal episodes, which we're
going to continue, right, just because we're doing the sponsor
spotlight. It's in addition to the normal
content we do. But I felt like that's been a
limiting factor in some ways. So I'm kind of excited that you
know what we're going to do today is we're still going to
talk about problems and solutions, but we'll also ask
our guests to talk about, you know, how does their product
solve this problem for the industry.
Yeah, that's all the stuff that I like to hear.
It's like, OK, that's cool, cool, cool.
Let's stop talking and let's start doing And they're doing is
the hard part. So why don't we go ahead and get
this thing started. Joining us today, we've got
Sandy Byrd. He's the Co founder and CTO of
Sunri Security. We're gonna talk about Clyde
Denning Security. Welcome to the show, Sandy.
Hey, thanks. It's great to be here.
Yeah. Thanks so much for taking the
time with us. One of the things we like to do
is we always like to find out sort of the origin stories.
The folks that we have on the show, you've got a background in
this for sure, so why don't we start there?
Tell us a little about Sandy Byrd.
You know, how did you get into the digital identity field and
is it something that you chose or did it choose you?
It's funny, I think security is general, you know, chose me.
I ended up ending up in security many, many years ago.
I started a company called Q1 Labs with a couple other people.
I was one of the Co founders and we did a lot of, we'll call it
threat based security right. We found a lot of security
intelligence stuff, did a lot of looking at log data, those types
of things. The company was great, it was
very successful. It was acquired by IBM though
and when I went to IBMI ended up in the role of the CTO of their
security division. And as that I had all the
security products and if you know IBM and it's history, lots
of identity products, right. So I had a lot of identity
products and learned a ton about, you know, everything from
access management to directories and all the crazy things that
happen in identity. And that was really interesting
to me because it was a space I hadn't spent as much time on.
At the same time that I was at IBM though they were also, you
know, transitioning tons of stuff to the cloud.
And in some ways at that time IBM was even trying to build a
cloud. I think you know they do a lot
more partnership with the the major cloud preventers now.
But because of that I kind of had both sides of this going on
at the same time. I was learning about identity
and all these things and at the same time I was learning about
you know cloud solutions. You know how you scale stuff do
this thing in the cloud. And the the common thread in
that was that in cloud the identities were the controls for
everything. They were in some ways like the
firewall of the old on Prem you controlled who could do what,
what workloads could do what. All of these things by
identities, including how you deny things from happening using
identities. And so it was this kind of
interesting kind of mesh coming together for me.
I really wanted to get into this.
You know how do we secure cloud platforms?
And so we founded Summary Security to do just that
actually. And the the premise behind most
of the primary controls in summary are identity based.
And so you know, security found me.
I found Identity a little bit coming out of the other side of
it and it's an exciting topic and super happy to be here.
I think this is your inaugural vendor spotlight now.
So it's the first one, so super happy to be here with you guys.
Yeah, thanks for that. I think you know we're figuring
out so kind of joke like we'll do it live, kind of figure this
out as we go. You mentioned Sundry Security
and I guess this cloud Identity security.
Well, obviously we feel like Identity is at the center, why
the podcast is named what it is? Tell us something about more
about the organization. What is the sweet spot, where
are you kind of focusing on your efforts?
Is it cloud specifically? Are there different clouds or
are there multi clouds like how do you look at it?
Yeah, we again, as you do a start up, you have to focus
somewheres, right? You know, identity and clouds
are both very big things and very big topics.
We took the primary cloud providers where people are
building applications, so AWS, Azure and GCP.
We support a few of the other ones to Oracle and things, but
the primary ones are definitely AWS, Azure and GCP.
As you look at that and you say you know how is the
organization's agent set up, like where would you focus your
time? I would split those, you know,
one third, one third, one third. They have completely different
identity models. Every one of them is so
different compared to the other one.
And they all have their their quirks for sure and they all
have their features, which is which is interesting.
And when you dive into each one in depth, you can, you can
really uncover some interesting things that maybe you did or
didn't know about those those cloud providers and the way that
they deal with identities, the way they deal with audit, the
way they deal with all these things.
And so from Sunri as a company, we focus a lot on that,
specializing in what makes up identity in these clouds, how
you control it, how you get it to least privilege all of those
types of things. So the name Sunri, Where is this
coming from? So another great thing, if you
create a startup now, you have to have a domain name that's
important, 100% you got to have a domain name.
However, if you wanted to create a domain name with identity or
data in it, well, they're all gone.
And they were gone long ago. So we had to figure out, OK,
well you know what's another way that we can, we can talk about
this. And at the time, we had a lot of
focus on how does an identity get access to data.
Because the premises is if you had your most sensitive data and
you knew everything that can access it, every identity that
can get access to this data, you had a hope of securing that
data. Well data in Gaelic Irish is
Sunri, so it actually means data.
It's a kind of a nice domain name.
Now the what we would say the I on the end is not actually an I
in Irish Gaelic. It has a fidal on the end and a
little a little accent. We own that domain too.
I don't think anyone's ever gone to it.
But anyway, we own the one with the the, the interesting Irish
spelling of of Sunri as well. But it's a good story and it's
kind of fun, actually. So.
And no one can pronounce it, of course.
That's the yeah, that. Was my next question.
It's like how many people have called it San Ray or San Rhee or
whatever variations are. We've gotten them all,
definitely. Sun Ray is a favorite of many,
for sure, So we we go with it. No matter what people say.
It's like, Yep, we know that they're talking about us, so
it's fine. Well, that's the hard thing.
I think about text on the web, right?
It's kind of like you see it. And then at least for me, I
start hearing it in my head, my inner voice, and I start
pronouncing it that way. And the next thing you know,
that's just the way it is. Well, I'm glad you got the, I'm
glad you got the domain names because whether you're starting
a company or a podcast, you need to have the domain name, you
know, set up for that. Let's talk about this field of
cybersecurity because Sun REI guess I'd like to understand
where does it fit because there are so many tools in this space.
There are a lot of tools just in the cloud space, right?
If you think about this as like a Galaxy, there are probably
solar systems full of things that are, you know, related to
cloud. I guess where do you guys
position yourself from a market perspective?
And then if there are any like unique gaps or challenges or
things like that where you know this is our sweet spot.
You know, if I if it was a fastball down the middle, what
would you crank and turn around, to use a baseball analogy, which
I know Jim will will be happy with.
Look, and again, sometimes we get to define these things and
sometimes the market defines them.
And so what's happened in the security space is there are
definitely a flavor of solutions that are cloud based, right.
And you can see that happening through lots of the different
analysts. They have many acronyms for
these things. And so I always split this
between what the world is currently causing.
They're going to call it CNAP, Cloud native application
protection, which involves everything and literally
everything here from like developer infrastructures, code
scanning, Kubernetes, security, all of what they call CIAM which
we specialize in the cloud infrastructure entitlements
management as vulnerability scanning.
And it has everything, It's like a whole gamut, it's its own
solar system but only for cloud. And then on the other side of
it, you have Pam vendors, so Privileged Access Management,
you have the Just in Time access solutions.
We have a bridge into that. So we kind of sit in between
these two sides and we really you know if you had to throw a
baseball down the middle, we literally land in between this
kind of cloud native application protection and this world of you
know Pam. And and the other side of this,
we really do specialize in the the identity entitlements
infrastructure side of the side. That's where we focus at Gartner
would call it Kim C i.e. M However, you know, we believe
in the future that probably lives somewhere else in one of
these other families. It's not just a singular thing.
So yeah. I've heard it marked it as like
Kim Keem. I feel.
Kind of feel like is this Pam 2.0?
I don't know. You know, I kind of asked this
question. Of course, like, OK, well, if
everybody's moving to the cloud, infrastructure's moving to the
cloud, that's where your privileges are.
Are we just evolving into another iteration of privilege
access management or is it truly a separate space like cloud
infrastructure entitlement? Management again the the future
will tell us the complete answer to that.
But there's a couple of interesting things when we think
about Pam vendors traditionally you know we could lot of talk
about lots of vendors cyber arc, whichever that have been in the
space forever. They classically would look at
workload identities as a vaulting problem.
You got to take the secret, I got to put it in the vault.
The workload has to grab the secret out of the vault, use it.
We rotate that from time to time.
Life is good and then Pam is more of an human thing, right.
Is it the privilege that the human gets?
When you move into these cloud vendors though, the blur of
these two things comes together really, really quickly.
Because even in something simple like AWS, if you're using like
SSO for single sign on, once you've signed on with SSO,
you're now a role inside of AWS, which is not really a human
identity anymore. It's a thing that goes and does
stuff. And then all of the workloads
also use roles so that they Lambda function that's there
becomes a role and then that role does work.
And then what really complicates things, the roles can become
other roles through a role assumption and the pattern goes
on. And so now when you're
controlling identity in these cloud platforms for privileged
access, the problems of humans and workloads start to come
together in some ways. And you have to have a way to
look at all of that in totality because the humans can assume
the workload roles and vice versa.
And so you got to secure that whole thing.
So again to your your question, you know, does this become Pam 2
dot O? There's definitely parts of Pam
that end up in the solution for sure, right?
However, the clouds have done a pretty good job of dealing with
these. What we would have called, you
know, workload identities which you know had these keys and
tokens and things that we had to rotate all the time in cloud.
When you're using the cloud native stuff like an Amazon
role, as you're already using a short lived token, you don't
have to rotate that, it's doing it for you.
It's actually a better process than what we had on Prem.
However, you have to control what net canal can use the role
in all these things. So it's just it is different.
You know, I think the future will tell us exactly where this
thing lands. Is it Pam 2 dot O that now
includes a lot of different ways of managing workload identities.
We'll see as things move forward.
Yeah, I think this is a fascinating conversation.
It got me thinking about, OK, I I think when we think of the
cloud, we try to think of how we did it on Prem and how we're
going to do it in the cloud. I actually think with what
Sundry does and you know the idea of identifying over
provisioned accounts is something that I say, well, how
do we do that on Prem because the problem and we've always had
that problem on Prem, but we haven't had a solution.
So I think it's fantastic that it's being done in the cloud.
There, there is interesting, Jim, like in cloud, so many
things have happened that enable us to do things we've never been
able to do before. You know, you see that just in
the massive scale that comes out of cloud, you can scale yourself
into an insecure network pretty quickly too.
But the reality is there are things you can do.
And so when we try to do least privilege, what's interesting
about the clouds are because there's a bill for everything
you create, you create a new VM, there's a bill for it, you got
to pay. If you create a Lambda function
and it it runs, you got to pay the bill for that.
Because of that they have to audit this stuff and because
they can audit it, we can now build lease privilege roles
because everything becomes audited in a central way.
Now I will say there's a little, whatever you want to call it,
gotchas and all these clouds, they don't audit everything.
Actually there's some permissions that are audited and
some permissions that are not. There are some permissions that
when you run them, you know they they come out in the log data.
So we want to get into details. You know when you create a new
VM, there would be a log message that says new VM was created.
However, if you pass that a role at the same time, so that that
VM that's being created is now going to use an identity in the
cloud that uses a permission called pass role.
Pass role is not audited in the cloud data, it's actually part
of the create instance message. And so there's some some things
we have to do to understand exactly how all of the
permissions and the API calls and all the things link into the
audit, that the audit is there for the first time where I'm on
Prem, we'd have to go to 50 different places to get this
data and and try to do what is is least privileged.
So it really does allow us to do things that we haven't done
before. The other thing is, is that when
you're dealing with custom built on Prem applications, the
permission space is almost infinite.
You don't know what everybody did, so you don't know what
permissions are there. When we deal with the cloud
providers because these are services and they have public AP
is we know every single permission that's there and so
we can inventory those. We can actually say, you know
this permission, you know create Internet Gateway is super
sensitive because it's going to poke holes in your network.
This permission list bucket, OK, well, you can see a list of the
S3 buckets, but it's not that sensitive.
And so you can risk rank all of these permissions in a way so
that when you're going to least privilege, you know we always
say sometimes you know least privilege is really complicated
like the truest sense of it, you know, use it or lose it.
I don't think anyone ever gets there.
My marketing team may say so, but I'm not sure that it's real.
However, for the really sensitive permissions, you can't
leave those things hanging out there for things that don't use
them. And so because we can risk rank
all that, we can build least privileged policies that work
really well but aren't super restrictive to the general user
when they log in. The console doesn't break those
types of things, so yeah. Yeah, I I feel like a large part
of my day job now is, you know, looking at Identity in the
cloud. I mean really doing an identity
strategy assessment of recommendations without pulling
in kind of a cloud focuses, you know, that's so yesteryear at
this point. But what I feel like is the big
driver, maybe this is the killer use case that you know you and
Jeff were talking about earlier is I haven't seen a situation
where a company said, hey, we're thinking about using AWS or GCP,
let's stop and pull in the information security department
and do in the most secure fashion possible.
No, what I've seen the most is the developers go out there and
they build this thing and then they move on and build the next
thing and the next thing and then information security says,
well, we really need to get our arms around this.
We need to secure this thing as well as our on Prem.
It's got to follow the same policies.
We need to have visibility into this environment.
And then how do we do that without becoming the progress
prevention department? To me, that feels like one of
the biggest security threats any organization faces when it comes
to the cloud, and I'm wondering if you see it the same way or
there's something I'm missing. Now you've you've you've hit it
exactly. The whatever we can use the
technical debt term here for sure, right?
The the developers built and it worked.
They were able to scale stuff. They were able to do stuff they
weren't able to do before. So then they put another
workload in the cloud and another workload in the cloud.
And so this is frigging great. It's amazing.
Then they turn the security features on and it got a little
more expensive, but it was still fast.
So we continued down that path and then the infosec guy showed
up and said whoa, what are we doing here?
We've got public S3 buckets. We got to close those down.
So we started to actually do some, you know, whatever, cloud,
security, posture management, CSPM, we started to do that.
It's just now really the identity teams are starting to
get involved. You know what I mean?
For the first time, they're taking a look under the covers
and said so. So where did happen to all those
vaulted identities we used to have in cyber?
Where did they go? Anywhere.
So, oh, well, they're we use, we use rolls.
Now you there's just lots of them.
You don't have to do that anymore.
It's like, well, who inventoried the rolls?
Are they supposed to be there? What permissions do they have,
all these things, you know, it's definitely I've I've seen maybe
one customer that tried to plan up front for what they were
going to do. Everybody else is just, you
know, it's the Wild West to the point that they try to gain
controls in it and that's what you get in some really
interesting differences in the cloud.
In AWS and GCP you have a a model where a deny wins and it
allows you some semblance of centralized control if you want
it. It's pretty easy to break stuff,
but the reality is you can actually say don't allow X to
happen and it will be denied across that whole
infrastructure. In Azure, it's an allow model.
If any one thing gives you permission, you've got
permission. Doesn't matter what all the
other rules say. And so it's to look at the two
different clouds. When you're doing these
assessments, you have to think about that stuff because again,
the way the permissions are laid out and the controls are
different in each one of them. And so again, rather than using
sundry, you know, we have great ways to analyze all that,
understand how the complex rules get, you know, put together.
And then do you actually have permission or do you know?
And then can we build you a better role, better policy, or
even just you trying to do a manual assessment of it.
You have to understand how each cloud works and how the identity
models work in it to do it right.
Yeah, Speaking of sundry. So is this the time where you
know and information security steps in and says we need to
have visibility into what's going on?
Do they at that point look at Sunream and say, oh, this
provides us that that window into what's going on?
Or is it that development team as they're building things, they
say, oh this, that's all we need to get things set up?
It and this is an interesting history of this company in
general. I think when we started the
company you know we thought that the developers would want to get
to least privilege. I don't know why we thought that
who would ever want to get to least privilege but but you know
you thought that the that the the goal of these teams was to
build a beautiful kind of secure platform and least privilege and
then you Fast forward and what you realize is is that every
time we tell somebody you know this workload is over
provisioned you have to fix this role.
We can automate that using bots and all these things, but it's
work for somebody because anybody with a really mature
development process needs to do that in development.
They need to promote it to UAT, they need to run all their
automated tasks, They needed to promote it to prod.
And there's a we would love to say it's completely automated.
There's a human involved somewheres in that process if
you have a good software development process.
Whereas you know you look at it now and I actually think it is
more the backwards tonight. It's the info sex guys coming in
saying we need to get visibility.
What's going on here? We need to see how bad of a
situation we're in and then build plans to figure out how to
take some of this risk back out in big swatches.
Not just like, OK, we're going to fix one roll.
Where are the big things? What are the big swings we can
take with the bat to fix this? So again, when you look at it
that way, that's more the, the common pattern and we've split
our our product into two ways of doing that.
If it's a, we'll call it a a company that's still looking for
that initial hit of visibility. They just don't know be like we
don't know how bad it is we want to see.
We have something called a cloud identity diagnostic.
It's kind of a once and done, we run the thing, we analyze the
whole thing. We find all the lateral movement
paths, all the least privileged policies, whatever.
And we presented as a report. We say, you know this is how
many administrators you have. Some of them are people, some of
them aren't. Some of them are getting the
permissions directly, some of them are getting them
undirectly, whatever. And we give you this nice report
that kind of shows everything and then you can figure out from
there like, OK, systemically they have a really big problem
with unused identities. Most of our identities are
unused. I'm going to go fix that.
The other company profile is they already know they have a
problem and they're trying to get a system in place to
actually start to drive. OK, what's the biggest risk we
have from all of these over permission roles that are there?
Again, I use the word role, that's an AWS thing.
In Azure, the role is also a role, but it's it's done
differently. But whichever way, we need to
basically build some form of least privilege and what level
of that is and have a way to basically measure that to make
sure we're getting better over time, right.
And so we have both patterns. We have the the people that run
it 24/7. It's always looking at the cloud
all the time. It's always generating new least
privileged policies. It's always finding risk from
lateral movement. And then we have the customers
that are the well once and done right.
I just need to see what's going on for one shot so I can build a
plan a year from now on how I'm how I'm going to deal with this.
Yeah, it seems to me those are are fantastic examples.
Seems to me that one of the areas that the Kim space really
excels at is for organizations where you've got multi cloud.
So that's interesting. I work with a lot of
organizations and they're always have a plan to get down to as
few clouds as possible. But to me, it's like the clouds
are like continents. It's like, yeah, we live in
North America and Europe and Asia, but we're just going to
have homes in Asia and North America going forward.
Like, OK, well, that's still a lot of real estate.
And you know, what's your plan to get from one to the next?
Put that aside. I mean why is it that a Kim
solution really helps with and Sundry for example?
Specifically, how how does the platform help manage that multi
cloud environment? Yeah and multi cloud is an
interesting, you have a whole other conversation about you
know multi cloud versus singular cloud and what people actually
do and what we see in the field. When you have multi cloud though
you need to have some form of governing rules right.
We need to make sure that we don't over provision identities
that can create network resources or whatever it is.
The way that that's done in each of the three clouds will be will
be different. You know we need to have key
rotation that'll be done differently in in the different
clouds. And so when you're trying to
measure that at the top level, so you're somebody that has
multiple different clouds, multiple different teams
building and you need a common way to measure team A against
team B to understand where you need to put your resources to
fix things. We really help solve that
problem. We have a maturity model where
we can kind of grade the teams based on the maturity.
And even though they're building in different clouds, we can tell
you that this team needs more help than this team in terms of
least privilege or in terms of access or wherever those those
areas are. So it's a great way to measure
and compare teams, gamify it a bit, right, try to get everybody
to the the moderate level or the advanced level of maturity
regardless of which cloud they're in.
So that's great on the measurement side, it also allows
you, let's say that you're primarily in one cloud, you're
mainly in Azure, and you know Azure really, really well, but
you have a a side project in GCP.
Well, you may not know how all of your controls that you've
done an amazing job implementing in Azure Translate to GCP.
But when you use a platform like Sundry, we're going to be able
to measure those Azure workloads and say, yeah, these look really
clean actually you don't have problems in this area, this area
and this area. But in GCP it doesn't look like
you're doing a good job on service accounts because you're
allowing the service accounts to do things that you would never
have allowed them to do in, in Azure, right.
And so you can see that delta between those two clouds and say
look we, we got to make sure that we put these controls in
place because we're obviously doing a good job in this cloud
and and not in this cloud. And so it gives you a vendor
that's kind of building out all that content for you in that
common measuring of of those things.
So again, most of our customers I would say are multi cloud, but
it's classically that we're primarily in one and we've got a
side secondary cloud. I think a lot of times you know
companies have it for even disaster recovery or whatever
you want to get your data out of that cloud just in case.
I I can't imagine what the day would look like when Amazon went
away, but it would. It would be a.
A bad day for all of us, but if it did happen, you know if you
write these plans up for a company, it says you've got to
have your data in two places and that's the way to get it in two.
Places. So is that what makes the cloud
difficult? Is it the multi cloud aspect of
it and the fact that each of the clouds has basically their own
operating system and their own language to security controls?
I guess I'd like to understand specifically like how do you
guys make that translation to say hey I want to remediate this
issue, we have this policy and we don't want that to work.
Can I click a button and somehow it figures it out?
Magic. Figures it out, yeah.
And it's not even. There's this level of analytics
even before the fix that says maybe it's already fixed.
So if you were to look at any one of the clouds and you were
to only look at Jeff's direct entitlements, right?
And you looked at your entitlements and it said, you
know, Jeff can do this very nefarious thing, whatever you
can. GCP has these interesting things
where you can act as something, so you can basically act as
something else with the scope that you have, you would look at
that and say, wow, that's that's bad.
We should we should fix that. But the reality is GCP allows
for deny statements that are above that point that inherit
down. And.
So if the deny statement says that Jeff can't do that, then
Jeff can't do that right? And you may have a full deny.
And so you have to do some analytics to understand what the
real effective permission is for any given identity so that
you're not, you know, sending off false alarms saying this
permission is way too sensitive for this identity to have when
in reality you as a great cloud architect have architected the
identity system to not allow that to happen anyway.
So in AWS is a similar thing. They have SCPS that actually
block these things. So you have to understand this,
every one of the clouds, those completely different in how they
do that. You know IDEA AWS has about 11
different ways that you can add or remove permissions through
this tree and they support wild cards and other things that that
caused a GCP has a much simpler model which is very much an
inheritance model. But scopes are really important
in GCP because you want to make sure that you get it's almost
like least access instead of least privilege.
You want to get the scopes of these permissions down to the
most granular thing that you can get.
Especially things that are sensitive like act as and so you
have to, depending on the cloud, completely translate what
they've done into something that's actionable.
Then you get to the button. So now we're finally at the
point that we have the the thing we have the least privileged
policies not appropriate. We want to put it on there.
Now you need to actually go and press that button.
Some of the things are direct fixes, Jeff.
It's so great. You know it's like OK, well this
identity has the ability to act as it's never used it or it only
uses it in one scope. Press the button, we fix it,
it's done and over super easy. Some of them are not so easy.
So in AWS you can assume a role and you can do that across
accounts and so you may have one.
We have these lateral movement change which could hop from
literally one account to the next account to the next account
to the next account. And they've parts of them have
never been used. They were all put there
intentionally for little parts of the path to work, but never
for the whole thing to be combined.
And so when you look at that, the fix for it is often not on
the thing that starts it and not at the thing at the end.
It's somewhere in the middle and we will find the thing in the
middle that you can break that chain and and cut it off.
So that's another kind of interesting thing when you look
at fixing it. Now the development teams have
really messed this up, though I shouldn't say messed it up.
They've done an amazing job. They deploy infrastructure's
codes, so they use Terraform or whatever they're using Those
infrastructure's code platforms have state in them and they know
when the state drifts. So now pretend you press the
button, but the state now drifts and they redeploy it.
It fixes it. So now there's a problem that we
automate to fix, which then the Terraform puts back and you end
up in this fighting world between them.
Who wins, right? And so you have to be aware of
the cloud architecture, how? What created this resource, how
is it being maintained so that you can tell them how to fix it
properly. Is it fixed by pressing the
button and that's going to work? Is it fixed through some form of
automation or do you actually have to create a ticket clear
back to the development team and say this piece of Terraform
needs to be adjusted because it doesn't have the right policy
attached to it and so you have to be aware of that whole thing
kind of end to end as you do it. I have a theory which is that
all of the the senior information security folks like
myself, we had a heyday. The heyday would be when you
would sit there and read technical articles or books
while you were eating your meals because you couldn't break away
from it and you really understood all the technical
aspects at that time. And over the years or decades
things have changed. So I remember the days where you
would put ACD or DVD in a drive and you would build the server
from you maybe boot to a diskette, etcetera.
And then there was VMS and hypervisors.
And I remember trying to explain to my management what was going
on with VMS and hypervisors and they looked at me like I had
three heads. Later on you get to the forum
where there's not even servers, you know.
And so I I think that's where things and how they operate in
the cloud become so abstract from what your basis of
technology knowledge is. Anyway, this is a little bit of
a rant for me, but I I actually don't think that the cloud is
necessarily more complicated or complex than on Prem.
I just think it's it's different and I actually think that the
Kim tools and the ability to do over provisioned account
analysis is a major breakthrough because I I think what it boils
down to is that the the cloud platforms have the logs and
you're on Prem generally doesn't have all the logs needed to say
this account has too much access.
You should start ripping off that access.
You rip off that access and it might have unintended
consequences. So again, that's just kind of my
rant, but I did want to, I was also thinking of something that,
you know, as you and Jeff were talking is I run into a lot of
clients these days. And you know, Microsoft is kind
of making a stance in every aspect of identity, including
cloud identity, including Privileged Identity Management,
especially when it has to do with the Azure data center
environment. And it got me thinking, OK,
well, is that all the solution that certain organization need,
maybe like to hear your input on that?
But then when is the switch flipped?
Where it's like, OK, now, now I need Sunri because there's some
kind of gap in what I've got and what I need and and how does how
does the practitioner who's listening to this podcast know
when that switch has been flipped?
Yeah, that. So first of all the multi cloud
thing always comes up, right? If you have more than one cloud,
then the the Entra solutions which they've nicely renamed.
The Entra used to be Azure Active Directory and a whole
bunch of different tools. Now it's Entra.
That solution you know probably starts to wear pretty thin if
you're trying to use it to manage Amazon and stuff.
It will do some things in Amazon, but it's it's pretty
weak in what it does. However, let's pretend you're an
Azure only customer and that's all you've done.
Then Entra actually does some nice stuff there, right?
You know, you can actually get it to do PIM as an example,
Privileged Identity Management and you can build assignments.
It's sometimes hard to get it to scale to the, you know, massive
management group structure and all the subscriptions you have
and figure out who the owners and everything are for these
things. But it has the basics of it
built into it, which is quite nice.
It does have some semblance of least privilege for certain
things, so it will generate some least privileged roles.
We have to use the right words in Microsoft.
Their roles, they least privileged roles for some
things. What's interesting about Sunri
is is that we tried to create this balance between perfection
and usable and we can build you perfect, perfect roles.
But the problem is, say you have 100,000 identities in Azure,
that's 100,000 custom roles, and I don't think anyone wants to
manage 100,000 custom roles. However, we can get you good
enough. What if we take the people that
were contributors, which have basically all of the permissions
except being able to grant other permissions and move those to
something that looked a lot more like a security auditor role for
the stuff that they don't use. But for the two services they do
use, we still give you the the the you know, the create,
update, deletes that you need. That's a much easier to consume
role that you can use across many identities and probably
doesn't break the console if that happens to be a person that
logs in later or when you add 1 new feature to that app that it
was gonna use. And so we find that works quite
well. Entra's not so great at that.
They're good at sometimes the perfection and not so much the
the usable on that side. Yeah, you've got your head in
the clouds so often. And I mean that in a positive
way. Yeah, You've got to have some
horror stories. Like is there a particular,
like, oh man, it's really bad, or something else kind of like
you're willing to share. I don't want you to name and
shame anybody, but maybe it's just the situation.
We have had so many interesting things over the years, I can't
even begin to describe them. One of my favorite ones was
there was This Doesn't Matter organization and they had a lot
of like automation and workloads that they had built and the
workloads and the cloud services would assume these identities.
In this case it happened to be in in AWS, but it doesn't really
matter. They would assume these
identities and then those identities would do the things
for the developers. Found it amazingly hard to
troubleshoot this when it wasn't working.
And so in all of these cases across insane numbers of roles
AWS, they added a trust relationship to trust the
account that it was in. So and again, we'd have to get
into super details here. But in AWS you have a role.
It trusts something. It might be an SSO provider, it
might be another entity, it might be a cloud service, or it
can be an account. And by account it means
basically any identity in that account can use that that thing
with some conditions. This made it super easy for them
to troubleshoot because now the developer in the account could
just assume that role and do anything that he wants.
However, what it also meant was every identity in that account
could do the same thing. So if an attacker got even a
semblance of a role anywhere in the, they could become anything
they wanted across their like whole way that they built
development. And you're like, but it seems so
obvious to the developer, Oh, if I just add this one line, it's
so easy to troubleshoot, it's amazing.
But they didn't understand the impact that they were truly
giving everything in those accounts access to to do this
right? And it was.
It was an unintended consequence they never meant for.
They had another customer one time that had an issue where
they were using Cloudfront and they had given Cloudfront needed
to read data out of data stores and that was fine, but they gave
it read and write because it was easy to.
I'm not even exactly sure why they did, but the problem is
Cloudfront's an Internet facing identity that now can write data
to the thing that it's supposed to be reading data from.
It's really easy to manipulate the website that it's facing on
the other side. And so he's like no one ever
thought I was like, oh, the cloud front can do that.
It's like, yes, you gave it permission to do it.
If the attacker can manipulate it in a way to get it to write
the right thing, then you know you can you can change things.
And so there's many horror stories over the years that we
we run into in these ways. And again, we will, we will keep
everybody nameless that those things happen to.
But lots of fun stories. So I want to pivot to a blog
article that's on your website. It's called 4 Steps to Secure
Cloud Identities. If you're stuck, first of all,
great SEO. So yeah, that's a great title,
people pick that up and it's actually and I and I hate to say
this because I'm, you know, dump on vendors all the time, but
it's actually a good article and it's a good entry into things
that people should be thinking about from a identity
perspective in the cloud. I guess why write this like, who
is this blog for? Is this for the admin?
Is this for somebody who's doesn't know where to start?
Help me kind of take me behind the mindset of of how this came
about. I I we actually wrote this blog
mainly because we had I'll call them customers sometimes
prospects people we were talking to in the industry that were
super frustrated with the state of identity in their clouds.
So we run these cloud identity diagnostics and we would come in
and we would say, you know, you have, let's say 20,000
identities that aren't even used.
If you want to break your lateral movement paths, you
should delete those first. That's going to be the easiest
solution. And people are like, wow, we
didn't even know, right. And so we found that everyone
would come talking to us with like these really complex
identity problems. We want to get to least
privilege. We want to put perfect policies
on anything. We want to basically automate
the developers getting the code right as they come in and all
the stuff. And we would look at them and
say, but that's not where you should actually start.
You should start by saying you have a lot of administrative
accounts in your cloud. Some of them are not used.
You need to basically say which administrative accounts are
break glass. They're not used, but they're
supposed to be there and which ones are stale and need to be
removed. And you need to do that first
before you do anything else. If you do that, then we now know
the unused identities that are supposed to be there.
And what that means is now when you look at the 20,000
identities that are completely unused, you can delete them with
automation because you know that they're not supposed to be there
and they're unused. Great.
That actually will break huge numbers of lateral movement
chains, and it will remove a whole bunch of work you were
supposed to do for least privilege, because now those are
at least privileged, they don't exist anymore.
And what that leaves you with is when you then build your least
privilege, the amount of work you have to do is far less.
And when you fix the least privilege, most of the lateral
movement chains will break and then you'll be at the point
where you're actually in a huge improvement over where you were
maybe as much as just a couple months ago.
If you do this work right and get it done, you could probably
automate it all in a day. But big enterprises take longer
to do things than that. But you can do that.
But we found a lot of customers coming to us that would want to
do these very complex things and they would want to do all these
crazy tasks and you're like, but you need to start with the
basics. And it reminded me so much of
my. Career earlier in you know the
security and threat intelligence and we would go and people would
want to do machine learning on log data and they would want to
do all these anomaly detection whatever.
And we would ask them simple questions like did you salt the
password file They'd be like no. Like you need to go back there
and do that first then we'll do anomaly detection.
And this is a similar thing. People have to start at the easy
stuff and automate it and get their their process in place.
And if they do that, they will be in such a better place than
where they are today. Other than being frozen in, I
don't know what to do. It seems so complicated, right?
And it's not. And there's other ways to do,
like again, the blogs about us and how we solve things.
But you know what? You can go to the AWS console
and look for your unused roles. You don't need a fancy tool for
that. You can go and get that data out
of the AWS console and start removing those, right?
You need a process to certify your administrators.
You can do that with summary Security.
There are other ways you could do it, right?
So just doing that and getting the muscle memory on how to do
it allows you to automate it and do it fast and great.
It's amazing how much of security and identity security
is building block based in my mind.
Like if you don't tackle the basics, yeah everything that you
do on top of that is just going to topple over.
It's like a really bad game of Jenga.
And so I kind of look at it. There was 1 statistic in here
that I thought was interesting and it was basically up to 15%
of identities. I'm reading it right now.
Can self escalate their privileges?
Can you talk about what that means?
Yeah, it's it's different in every cloud and the way that
they work in AWS, it often means you will have given this
identity the ability. As an example, we see this a lot
where it can modify a policy or something.
Well, if it has a policy attached to it, it's identity,
it can change the policy to give it more permissions and now it
has escalated its own permissions.
In AWS you have something called assume role which allows this
role to become another role. Well if that role that it can
assume has more permissions than itself, it can escalate its own
permissions. In GCP you have similar
scenarios where if you can, you know set IM policy on something,
Well if you can set IM policy on something you can get to, you
can give yourself more permissions and there by the
way, there's hundreds of these examples.
It's insane how many there are. And when we measure all of the
identities across the cloud, we discover that basically 15% of
them have this ability. That's really high.
Like if you think about a good identity system, you would never
have 15% of the identities can generate other identities and
give them permission. That's a really big set of
identities that could do that. But yet in cloud, we, a lot of
them are workload identities, but we allow them to do that.
And it's kind of unacceptable, but it's the reality of the
statistics that come out when you measure across lots of
customers. Is that something on the concept
of like 0 standing privileges as sort of like the opposite of
that where some of these maybe you know admin privileges are
self escalating for the right reasons because there is there
situations where yeah that actually is OK or is it?
Always bad. It absolutely is.
And we we have, it's interesting we do these cloud diagnostics.
We have some kind of statistics that say you know generally on
average people should be in these ranges and we like to see
those the ones that are intentionally kind of self
escalating and can add, maybe they're not even self escalated,
they just have admins. We like to see those in those
one 2% ranges. That's where we want to see
those numbers, right. We don't want to see them at
15%. And you know, the reality of
clouds, when we look at it, it's often the machine identities
that are actually over privileged, not always the human
ones. Everybody wants to run their
build role star, you say, but you only use 20 services out of
the 200 available. Do you really think it needs
them all? But we'll use them tomorrow.
OK, so let's make an exception for the build process.
Now let's go down the list of all of the things that came
after the build on automation process that have the same
problem, right. And so it is quite out of
control. In a lot of cases in these
clouds, it seems to me like this is a indicator of when Skynet is
about to become self aware. It's a different, yeah, it's a
different podcast. We'll go into the whole Skynet
thing and that side. I want to ask some product
specific questions. I kind of mentioned the shackles
being, you know, off. In a conversation like this,
what does it take to implement something like this?
If I want to set this up, do I need I'm I'm assuming and feel
free to correct me if I'm wrong, I need some sort of admin
credentials to give to your product to say, hey, connect to
this environment, this tenant, whatever it might be, right?
Those sorts of things. Walk me through what it's like
to set this up. Yeah, there's there's two sets
of permissions you always have to talk about.
There's a set of permissions needed to deploy it and then the
set of permissions needed for it to run, and we separate those
two. The person deploying it needs
pretty sensitive permissions because they have to be able to
put roles and accounts and and do things like that, and so
they're creating permissions and entitlements and stuff like
that. So it needs to be fairly
administrative in that scenario. And every cloud's a little
different. You know how it's done.
The system itself, if you're looking for the visibility
component of it, runs more like a security auditor.
It really doesn't have any administrator permissions at
all. It's really just gaining
visibility as to what's there, and it's suggesting this is what
the policies should look like in production or wherever you're
running them. However, if you're going to run
any of the automation, the bots to clean stuff up, the bots to
delete identities, every one of those bots has a set of
permissions that it needs, and we try to do this in this kind
of least privileged way. If you're only going to run 5
bots, then you just need to use the five permissions that those
need and no more than that, and that allows them not to be one
of those things that can escalate out of control as well
in your cloud. So it works fairly well, but you
will have to like we'll use the unused identity one, super
simple to clean up. But actually to delete an IM
user or roll out of AWS you don't need one permission.
You need actually more like 9 or 10 because you have to remove
the policies from it. You have to, you know, remove
its access keys. You have to clean up after
itself or the command to delete the identity will fail.
And so again, each one of these has their own unique set of
permissions to do it. But generally to get the
visibility security auditors fine, you don't need anything
too serious. It's only when you want to run
the automation that you need a little more permission.
How long does this take to run to collect all that information?
Is it like I need to run it overnight?
Is it days? Months.
Seconds. It's easy to measure.
The diagnostics are the easy ones to measure because that's
kind of a once and done so like once to the point that you're at
the state that you know everything that's going on.
There is a always a a sizing question to how big is the cloud
and there's another question as to how far back in time do you
want to go to understand history.
Generally 24 hours is what you're looking at.
If you have a really big cloud, a lot of accounts and you want
to go back 90 days in the past or 180 days in the past, it just
takes time to read that log data.
You can, you can scale it, you know, as you go, but at some
point in time you run out of calls to grab the data across
and transfer. So you know, maybe as much in a
really big cloud, three or four days or something like that.
But it's not. It's not forever by any means.
It's it's measured in in hours and days.
And what's it doing? It's capturing the data and then
is it doing like a differential? Yeah, that's exactly what you
can think of. So the, the, the discovery part
of it is looking at all the current entitlements.
You know, what does Jeff have for entitlements?
What does the build role have for entitlements?
You know, what has been deployed for resource policies on
resources, things of that nature because they all control
identities. Then it's looking at the audit
data again cloud trail and AWS activity logs in Azure, whatever
it happens to be. But it's going back those and
it's comparing the delta between what you've been provisioned
with versus what's actually been used to build those least
privileged policies. And you do need that history.
You know, people will often say, you know, I need, you know, two
weeks of history and I believe I'll be fine.
I think that's true in most workload identities.
If you can get a two week period, you probably know what's
going on. Humans are far less predictable.
You need much longer time frames to understand what humans do and
what types of least privileged policies you want to give them
and. Then I would assume there's
probably some sort of alerting or something like that to say,
hey, if I'm detected like an anomaly, right?
Or something's not the way I want it to be from a policy
perspective. How do I become aware of that?
Yep, there's there's, there's two.
I'll use it. You can use the word anomaly,
which is interesting. I will say there's two ways.
One is we have this insights view, we call it, which brings
to light all of the, you know, the misconfigurations and the
odd things that are going on. And it has some activity stuff
in it to say, hey, somebody just granted a new administrator
permission or something like that.
So that's more of an explore interface.
You can go in and explore what's going on.
You can explore how bad things are, how good things are, gives
you a nice risk score, things like that.
Then there's the I want to operationalize something.
I want to know if an identity has too much permission, or I
want to know if an identity hasn't been used in 90 days or I
want to know whatever those are. Those are, we call them
operationalized policies. And basically in that scenario,
you you define A-Team, you say we want them to react to this,
and then you define an integration for how you want to
talk to them. Maybe it's through Slack, maybe
it's through JIRA, maybe it's through Harvard.
You actually go and do that. Those same triggers can be
automated, so they can also run a bot and and automate that
process. So there's there's kind of two
parts to it. Then you used anomaly part of
and this isn't, is it the CIM space or is it UEBA or whatever.
You can talk about all these different spaces, but we
actually do a lot of profiling on the identities and when they
do odd behaviors and stuff, we generate alarms for those as
well. That's a whole another space.
I don't even know if it belongs in the CIM space, but it's
another thing that we do so. And as far as integration with
sort of other IT tools, I'm thinking of things like ITSM or
you know other SIM type tools. How does that work from like a
log perspective and working with other platforms that might be
the environment? Yeah, we're so we're obviously a
a SAS which sometimes is amazing and then sometimes terrible
depending on if you're dealing with an enterprise that has all
their tooling on Prem versus wherever.
So if it's the integrations with other SAS platforms, super easy,
right? You want to send stuff to Splunk
Cloud, you want to send stuff to, you know, the Jira Cloud,
the Elastin platform. That's all fine.
But say somebody has Jira on premise, right?
OK, well, that Jira, we can't talk to it.
It's no way to get in there. So it has to call out.
So we have things like apps that you put on Jira that call our
APIs to do that work and that works fairly well.
So we it's again, we have integrations with all of those
types of tools, The Sims or tools, all of the, you know, the
ticketing management system tools, all of the communication
tools for that. But the way you integrate with
them all depends a lot if that tool is a SAS platform or if
that tool is something deployed on Prem, there's a different way
of integrating with them. Any closing thoughts before
this? Because I want to talk to you a
little bit about EVs and electric vehicles.
I think you and I seem to be both be fans, but is there
anything that you'd like to kind of share as far as like anything
about sundry or what should people take away from this
conversation around cloud security?
Look, I think there's there's two profiles.
If you're the type of company enterprise and you really just
want to get that initial hit of visibility to see where you are,
you don't know and you're sitting there saying, I really
don't know where we sit in this, this gamut that cloud identity
diagnostic works well. You could reach identity of our
sales team. They would love to do one of
those with you. It's a super simple process, low
friction. In two weeks, you're done.
You have the report, it's yours to keep.
If you want to run one again in six more months, you can do
that. If you're the type of customer
that actually feels like you've got a handle on it.
You've written all of the deny policies and SCPS and Amazon,
you've built a beautiful identity model and you're really
worried that you missed something, that lateral
movement. Then Sunroof Security is your
company to basically figure out the stuff that you've
architected wrong in that in that platform.
And that's a different personality.
It's it's somebody that really cares a lot about their identity
models. We see it a lot in, you know,
large finance and places like that where they have put teams
of people actually building just phenomenal identity models in
their cloud. It it's almost kind of like the
best scenario is that you don't find anything, right?
It's like, hey, we were on a scan and hey, nothing came.
Up, nothing came up great. That's what you want, right?
That's what you want? I don't know if it ever happens,
but if it ever does, it's gonna be great.
Right. All right.
I wanna talk to you a little bit about EVs.
You and I are both EV fans. We were kind of talking before,
you know, the show started. And one of the things we do, and
this is still an identity at the Center episode, is we end on a
lighter note. And we're kind of talking about,
I wanted to come up with something EV related.
And so I'm gonna start with this one.
Imagine you could take any historical figure on a drive in
a modern electric vehicle. Your choice.
Whatever electric vehicle you want to use, who would you pick
and where are you gonna take them for a spin?
That's It's so interesting. And so I'm a car guy.
It doesn't even have to be an EV 'cause I just love cars in
general. And you know, if you had to take
some historical figure, I don't even need to go back for a fire
and pass, you know, like, take Carroll Shelby somewhere, that
would be kind of fun, right? Maybe I want him to drive.
I don't know. It's be interesting.
But I think, you know, people that ever built the original
race cars in like the, you know, 50s and 60s in that era and you
put them in a modern EV, it would be interesting to see
their face in some of the the rate and pace of these cars
accelerate for Rd. cars, right. You know, it's stuff my my
family often builds drag cars, right?
And they do crazy fast quarter mile times and then you take
them for a drive and a Tesla plot or something and you're
like holy, this is a road car. It's like, yes, it is a road
car. It's kind of amazing.
Now I will admit the handling of some of these E VS is not so
great. I'd rather have a very light car
versus an EV in many cases. But you say where to go.
You know, man, the Salt Flats would be a pretty cool spot to
go for a drive. One of these, because of the
acceleration and those types of things.
Somewhere where you can really, you know, unlock these cars over
a distance at speed and at pace would be would be fun.
You probably wouldn't pick, you know, the twisty turny back
roads of Isle of Man or something, which would be more
fun in a lighter car. So anyway, that's what I would
do. I would take care of Shelby to
the Salt Flats and we would jump in something crazy fast, like a
Tesla Model Plaid or some crazy lucid and we would just open the
thing up. It would be awesome.
Jim, what about yourself? I know you're not so much on the
EV side, but you got this giant truck.
Let's pretend you've got an EV. Who are you going to take on a
ride with that? Well, actually, you know, one of
the great things about identity at the center is I can turn my
question into whatever I want and I don't care at all about
EVs. So I'm going to twist the
question of I could take somebody from the future where
everybody's driving EVs and I could pull them into the past
and drive them around in a fossil fuel burning truck and
show them what that was like. That's what I would do.
With a respirator and something else, right?
So they don't, they don't die. Hey, I don't know.
You know, maybe the the error's worse in the future.
Never know, you know you. Leave it to me to bring things
down there, yeah? Way to go Jim.
As always, Sandy, you mentioned the Salt Flats and I was kind of
thinking the same thing as like someplace where I can floor it
and keep it forward for a while. I would be, I would be afraid
of, you know, hitting like a Pebble at like 160 miles an hour
and like flipping. I'd like to bring somebody like
Nikola Tesla or somebody like that to say like, you know,
someone who was ahead of their time bringing them forward and
you know, hey, look, this car is named after you, right?
That kind of thing. And just to kind of see kind of
the expression of you know the the building blocks that came
before us to build that. But yeah, I'd love to get it
like a a lucid. Those are crazy fast.
I mean definitely the plaids on the Tesla, I have a performance
wise, so no slouch I'm I'm doing pretty well with that one and my
favorite thing to do in it is to surprise my wife and goose it
when she's least expecting it. So that's just a little thing
that I like to do to show that I love her.
Exactly. Her neck slams back against the
headdress. And it's usually followed by
some sort of cry or or something like that.
So that's how I that's the way I like to roll.
OK well, I think this has been a great conversation and thank you
so much Sandy. We're going to have a whole
bunch of links in our show notes for people to check out more
about Sun Reece Security SONRAI security.com.
I'm going to try to use the other eye, the Irish version of
it. We'll just go with that.
We'll have a link in our show notes to the four steps to
secure cloud and easy. You're stuck again.
Great SEO name. So kudos to whoever's put coming
up with those blog titles. And then of course Sandy, if
you're open to it, we'll have a a link in our show notes for
people to connect with you on LinkedIn.
If they've got questions or wanna get more information,
hopefully you're good with that. I did do a demo of your product
in the real world outside the product, I was really impressed.
So I would definitely encourage people to take a look at it and
see what you guys are kicking around over there.
It's it's pretty good. Anything else you wanna add
before you wrap things up? No, look, thanks for having me
today on the inaugural, whatever you're calling this particular
series, but I'm glad to be the first and hopefully all the
other ones are just as exciting. Yeah, we appreciate that.
And yeah, well, we, we did it live.
I feel pretty good about the way the conversation turned out.
It was very educational. I learned a lot and we'll go
ahead and leave it there. So you can find us on the web,
IDC, podcast.com. And thanks everybody for
listening and we'll talk with everyone 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 and find
us on Twitter at IDAC Podcast. See you next time on Identity at
the Center.