Latest / Identity at the Center / #251 - IDAC Sponsor Spotlight - Sonrai Security with Sandy Bird

Transcript

#251 - IDAC Sponsor Spotlight - Sonrai Security with Sandy Bird · Identity at the Center

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