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. I'm excited for today's sequel.
This will be the first sequel we've had on the Identity at the
Center podcast. Yeah, we've got another sponsor
Spotlight episode. These are fully sponsored
episodes that we develop in collaboration with our partners.
And we're very excited to welcome back our first sponsor
Spotlight, which was Sundry Security.
We actually had Sandy Byrd join us way back in December of 2023.
Feels like so long ago, but welcome back to the show, Sandy.
Hey, thanks for thanks for having me back.
I just couldn't stay away so so much fun last time.
I think we talked about EVs at the end and Heroes.
We took an EV car, so it'll be interesting to see what today
brings for interesting topics. And we kind of kept that EV
conversation going because we were talking before we hit the
record button about EV stories and things like that.
So I feel like there's this natural affinity there.
But let's talk about Sun RE because you've got some new
things that you guys have announced.
I want to get to that in a second.
Now this is your second time being with us, so I'm not going
to make you go through your background.
You want to hear that? Go back and listen to episode
251. We asked Sandy all about how do
you get into the Zion space, but we do want to ask about sundry
security. Tell us a little bit about what
you guys do. Yeah.
And Sundry Security has been around for for several years and
we've spent a lot of time trying to get customers that are using
Cloud, AWS, Azure, GCP to least privilege and remove a lot of
identity risk out of their cloud.
So in that other episode, we talk about you know kind of four
steps to doing that quickly. We talk about unused identities
and getting rid of them. We talk about finding your
administrators removing some lateral movement has, but we've
also learned a lot in those those few years.
And so Sunri as it's kind of developed over time has come up
with solutions to you know fix these without generating
hundreds of thousands of tickets for your developers to go fix.
And I think we're going to spend some time on that today.
We're we're building some pretty innovative solutions in that
space and it'll be a lot of fun to talk about.
Yeah, I'm excited to get into it.
You know there was a question that I that I wanted to ask last
time and this is something actually we have listeners ask
when we have folks like you on. And that's really is how do we,
how do your clients or customers measure success with Sunri.
And I imagine we'll probably talk a little bit about that and
when we talk about the the the new feature that you guys just
rolled out. But at a very high level, how do
your customers measure success with your solutions?
Yeah, it's again, every customer does this slightly differently,
but there's definitely key performance indicators, you want
to want to call it that. The solution itself always
measured a risk score, right. So you know, we, we take a look
at all of the types of risks that are there.
We kind of generate a score from it.
You know, maybe you get a 85 or something like that and you want
to reduce that down to a 70 or 60 or 50 or whatever you want to
get to. And you hope that your
production environments and where your sensitive data is a
low risk and you know maybe your sandbox accounts are are high
risk, but generally you want them all to start to get to be
at a lower state. We spent a lot of time trying to
help customers do that. And so you say, well, what's
success and what's interesting is some customers built some
great process. They kind of operationalized it.
They found those critical things they wanted to fix.
They generated tickets back to their teams to say, you know,
these applications and workloads you've created are not at least
privileged. Here's a recommended fix for
that. Maybe it's a new policy in AWS.
Maybe it's a better role in in Azure.
Apply that to the, you know, whatever the workload is, deploy
that out. You know now you're closed the
ticket. And So what would happen is, is
that those tickets would get issued, The teams would actually
do that. They would always test them
through, you know, some sort of a staging or UAT environment.
It would work. They'd move it to prod, the
ticket would close. In summary, everybody would be
happy. We'd celebrate.
And So what happens is over time you close more and more of
those, the risk goes down and everybody's is kind of
celebrating. But when we actually started to
measure ourselves against that in a way we would find things
like, you know, maybe a customer fixes 2000 of these tickets over
a 10 month period and everybody's like this is we're
super happy about this. And then you look at their cloud
and you realize in the time that it took them to close 2000
identities, they've created 4000 more that are no longer at least
privilege. And we have to build a history
for that to figure out what least privilege is.
And that cycle starts all over again and you start thinking
there has to be a better way, right?
We can't. You know we have these
interesting customers that have you know, 50,100 thousand
identities that are workload identities.
If you're going to do that one at a time and have people test
them, not just like randomly rewrite the policies on them
all, which maybe I would say that you could do, but not
everyone's comfortable with. It's going to take, you know
you're going to measure this in months and years for success.
And I think you know customers today, we're all a little
distracted. We like these kind of quick
wins. We needed to find a way to get
to the quick wins faster and that's we're going to spend a
lot of time talking with today and the new product.
But you know customers definitely measure success using
those risk scores. Let's get those things lower.
I can show progress. Let's close tickets, right?
Issue tickets, close tickets. I can measure success that way.
But the real thing is, is like, is the actual cloud more secure
at the end of the day, right? And I think, you know, even
ourselves measuring ourselves as a customer needed a better way
for that customer to get to that point faster.
Sandia called this a sequel, and I think the best sequels are,
you know, a lot of the same characters, but a new story.
And you have a new story and it's you just announced this
thing called the 1st, the first cloud permissions firewall, and
by calling it the first it means nobody knows what it is.
So can you tell us what is the first cloud permissions
firewall? Yeah, there's a there was a lot
of discussions about using the word firewall.
Let me tell you, when we named this product there were it was
definitely a triggering word for everybody for pro or for con for
using this word. But we if you go back to that
original problem where we say we're trying to fix this 100,000
identities and we're fixing them one at a time.
And customers, we, we actually said customers are struggling
with this, right. If you didn't have a dedicated
team helping you know a lot of times the ticket doesn't get
fixed whatever it was and we said we have to flip this on its
head. The problem is, is every you
know, development team building a workload is free to create any
identity they want with any set of permissions that they want.
And across all three clouds you have like 4443 thousand
permissions. There's like today and you think
you know, do some relation back to firewalls, there's an awful
lot of ports and a lot of lot of IP space that you have.
And no one says, oh you can just have all the IP space in all of
the ports. It's not how the world worked in
networks. And so when we looked at the
permission space, it wasn't terribly different than that.
We were kind of letting the developers do anything they want
and we said can was there a way to flip this on its head to
create a default deny state And he said 43,000 permissions.
Most of these things are insensitive, but there are some
of them that are really sensitive, right?
Like there are permissions in cloud that allow you to take,
and this is one of my favorite ones, take the file system off
of this running workload and make it a URL on the Internet so
that you can share it somewhere. It's like who thought that was a
good idea, But it exists in these clouds and so there's
certain permissions that are super sensitive and how do you
put those in that deny state? The other thing we did to kind
of prove that this was a real benefit in doing it was we
measured like out of everything that has these sensitive
permissions in cloud, how many of them actually used them that
were granted them. And this is what got to be super
interesting, Found out that only like between 5 and 10% of the
identities that had them ever used them across all of our
customers. You know, you're just talking, I
don't know, millions, hundreds of millions of identities,
whatever it is, don't use these. So why is it that we're giving
them to everybody but no one's using them?
And so said, look, there's a way to do this where we can flip the
model on its head. We can make this like a firewall
with a default deny state. But the again, so now the
problems start. If we do that and then someone
needs the permission building a brand new workload that's never
existed before, how are we going to give it to them and not screw
up their work day? And so it's interesting, we used
all cloud native stuff for this. There's no in the firewall
itself, There's no like proxy, There's no, you know, jump box.
There's none of those things. It's all cloud native and it's
programmed cloud natively. But it puts this deny at the top
for the really sensitive permissions.
Everything that needed them from the previous history has access
to them, however, and that's only 5% of the things that were
granted them. And on day two, what happens is
as soon as somebody trips the wire and tries to use one that
never, you know, they never did it before.
But today it happened. And maybe it's a Terraform
script, you know, deploying some infrastructure, maybe it's a
Jeff just trying to, you know, build a crypto miner in the
cloud. Whatever it is, it happens.
They trip this wire and immediately in whatever they use
for chat OPS could be Slack, could be teams, whatever it is
they get in the team that's responsible for that area gets a
notification saying this just happened.
We want to give Jeff access to go and do that sensitive thing.
They hit approve. Jeff gets notified and literally
within one minute they now have access to that sensitive
permission. But it leaves that 95% space
basically never used and never granted and it.
So it's a completely different model.
And So what happens is, is that you kind of learn the history.
You put these firewall controls. They're not actually firewall
controls. They're using, you know, in
Amazon, it's SCP and Google, it's the deny bindings.
There's these other ways of doing it.
It puts these controls in place to create this default deny
scenario. And then immediately after that
goes into this permissions on demand model.
And so you have this immediate contraction of this risk value.
And so now you think about the summary platform measuring risk.
You all of a sudden go from the 75 risk to A50 risk literally in
five days and you want to talk about success.
You know, people can measure that and say, wow, I actually
made a difference in a few days. So again, triggering word again,
love to hear your guys's opinion on it, right.
You know, is firewall the right word for this or not?
You know, we, we said one time, you know, firewalls weren't
embedded for networks. We think of them that way
because we came from that world. But there was a firewall in my
PAN. There was one in an apartment
building between 2:00. You know what I mean?
Like firewalls are not unique to networks, but we as
technologists think about them as a network thing, right?
So again, it's it is this bit of a triggering word.
Love to hear your opinions, what you think, good or bad?
The last point was was spot on. So point number one, you may
know Jeff better than he knows himself.
You know, building a crypto miner.
If he was a hacker, I could totally see him doing that.
All right. Second thing is I'd love that
default deny as a starting point because even when you were
asking like is firewall the right term.
I've seen you back to my networking days and it was the
the death rule on a firewall was allow any to any right.
You remember that does that trigger something And then it
was like the smart firewall people knew that it was the
default rule had to be deny any to any you know and then you
start allowing things rather than working in reverse of allow
any to any and start blocking from there.
So to me it, yeah, it it's sensical.
I like the word firewall. I don't, I don't have a problem
with it. Jeff, do you have anything on
that? No, I think it's, I think it's
appropriate. You know if you're asking me,
I'm in a marketing meeting. I'm always trying to find with
funny names I would think of like you know the cloud
permission ban hammer or something like that.
You know, I'm looking, I'm looking at like Reddit or things
like that to have fun with it and that's why they don't look
at me to to name things. That's they don't.
I don't get the name stuff either.
You know we had a code name of it called Purple for the whole
time it was. It's still really hard to get
that on my head. I may call it Purple sometime
today during this call. But it, you know, it's it's good
to have code names. It's good to have unnames.
Too. That's a good little tidbit for
people who are listening. Right.
Hey, show me, show me your purple.
Oh, Sandy's going to know what that means.
I don't know anyone else. So maybe it might be weird if
you take something else. But that could be a way to
approach it. I do want to get into this a
little bit. I know that you we're going to
try something a little bit different here and look at it on
an audio podcast and we're going to try our best to kind of step
through it. But the goal here is to see it
in action so that Jim and I can ask some questions but also
encourage people. You know go to the website and
if you want to check out this and other things you can go to
sunri.co slash IDACSONRA, i.co/IDAC and you can actually
see the demo there and try it out and and so forth.
We'll talk about that a little bit, but I think maybe the talk
track of us and you showing it to us for the first time would
be helpful for us to ask questions and hopefully people
find it valuable out there. See Internet First, an audio
only demo. Of a of a visual.
Concept yeah we're we're all about first you know we were the
first sponsor Pocket. Now we're going to try the first
you know visual, audio only demos and we'll we'll see how
this works out. I think we're we're going to try
to be somewhat descriptive if all has worked well in the audio
world. You can see my stuff, though
Jeff and Jim correct. You can actually see a screen.
Yes, can. So I see a let's.
See a dashboard. Yeah, I see the interface.
I see. Let's see a few different
metrics here. So talking about sort of like
how you measure success, right? 3.1000 IM users and roles with
excessive privilege, that sounds bad.
How do we fix that? Over 1100 zombies?
That sounds even worse. So yeah, walk us through what
we're looking at here. Look we're we're going to do it.
So you kind of getting it right at the top of the interface.
There are these great statistics in four areas that you know
we're we're going to, we're going to look at and you know
the most complex one is kind of that first one you you talked
about where you have some number of identities that have been
granted these really sensitive permissions and then you know
they're not using them. So we should take it away.
And there's, there's these great buttons underneath of them that
people can't see, but you guys can see called like protect
identities or quarantined zombies.
And you know, those ones are actually quite useful.
But we even do things, simple things like regions.
And so if you come all the way over to this side of the
interface, you know, if you're not using certain regions, you
can actually just come in, click one or click disable these
regions and we will actually disable those regions.
Or if you have unused services, we can show you the services
that you're not using and you know you can disable those.
This is the thing that's really interesting with these cloud
providers though. Like every one of them has 300
unique services, but any given account or project that you're
working on probably only uses 20 or 30 of them.
And there's a whole bunch of dormant permissions in them that
are not being used that are latent that if when Jeff breaks
into uses crypto miner, you know, maybe you've never used
Lambda before, but Jeff can use Lambda to prank that thing,
right? And so we want to try to reduce
that attack surface, you know, as we can through some of these.
And there's there's obvious Security benefits to that.
But is it the potential cost savings to say, OK, we have all
these unused services, let's make sure we're not paying for
them? I I think there is now.
I always I always remind myself, you know you have to solve the
use cases you build stuff for and not try to make it too wide,
because then things get complicated for a while.
Do you solve this use case for cost and you solve this one, But
there's no doubt that, and this is the regions and the services
are exactly as you're saying, Jim, are the ones that
accidental things happen in, right?
Like, I think AWS intentionally makes it so that if you
accidentally spin something up in a region that you don't use,
you never see it again. And.
But it shows up on the bill every month at the end of the
month, right. And you know, the same thing
with services. Oh, I was experimenting using, I
remember this very well from our own sales engineering team.
You know some customer wanted to test something with that.
It was called a hyperscaler in Azure.
So they dropped one into the account and of course it ran the
demo account for a couple of other.
And I think the thing started at like $1000 a month, right.
And you know, until we caught it on the bill much later, you
know, no one even knew that was happening.
So absolutely there's a cost benefit there, Not our main
target market by any means, but certainly it's going to help in
those, in those areas so. So as I look at the interface
here, yeah, so I look at the interface here, I'm, I'm seeing
a list of services, right? So EC2 and this, these look like
AWS type things, right? EC2, Cognito, Alexa for
Business. And you've got different
categories across the type, account usage things say like 4
out of 10, a sensitive access of 15, the sensitive permissions of
eight. And then you've got a status
column that says, well, there's a couple of them, but
unprotected, partially protected, disabled, pending,
and then protected. And then there's like a little
button over the right that says protect, which looks like it's
for things that have not yet been protected maybe or
disabled. Can you walk me through kind of
left to right what we're seeing and what those figures and data
mean? Yeah, we wanted to make sure
that we could break these kind of default denies up in a way
where when you enable things, groups of things came back
'cause if you're, and I use the example, if you're going to
update security group rules, you're probably going to do
something with subnets as well, right?
There's, there's, there's these things that go together kind of
when you start to do them. And so it wanted to group them.
So you have the service as an example, you may have EC2 or the
IM service and it will have a group of these sensitive
permissions associated with it. And so you probably want to
protect all of those at once because the types of identities
that accidentally get granted EC2 star have all of the
permissions, but again, very few of them need them.
But the ones that need them probably need more than one,
right. And so we kind of group those up
the the sensitive, you know, you've got this kind of, you
know, sensitive permissions call and kind of tells you how many
in that service, you know, have sensitive or how many sensitive
permissions are in that service. And we did a lot of work on
this. This is where you know, we spent
time. Again, if you know enough about
AWS, as an example, an SCP space, it's limited.
You can't write SCPS that are massive.
There's all these limits you run into in terms of the size of the
SCP and how many you can have and all these things.
And so we had to be pretty selective about what we are
putting into those sensitive permissions.
And so we did all this work on, you know is this thing really
sensitive or not. And I, you know we got lots of
examples that way. And so again each one of those,
that's how many sensitive services you have and then you
have how many identities have access to that in those
sensitive services. And we can drill in.
We may do that in a minute. We'll drill in a little bit
deeper in a few of these, but that will tell you you know out
of the 75 that have access how many really use it 234 you may
we'll drill into that in a minute and then when you hit
that protect button, it doesn't actually protect instantly.
What happens is you click protect and it stages the
changes into like a pending changes state and that's why you
see that disabled pending, right.
So if somebody's made a a change, they put it into that
mode. What we actually do is we build
up this piece of infrastructure as code that actually deploys
all the cloud native mechanisms for you that actually implement
this firewall. And I think that's so important
because it's not like we wanted to be in the middle of you know
the the cloud intercepting every API call.
We actually wanted to use the cloud native mechanisms that
they've given you for putting these things in place and
utilizing those. So what we've done is
programmatically created that piece of infrastructure as code,
you as the customer then go and deploy that and so.
It's a way that you can kind of test this in one area of the
network, should call it a network.
We're now right into the firewall world, one area of the
cloud and account, you know, a project that you're working on,
you can protect it there and do that.
And so that's kind of all the calls we may drill into one in a
minute, you know, and then you know, we can go from there.
Again, I love those zombies and I I wanted to show you guys this
thing on zombies 'cause I think it's pretty neat.
Just like the services we can find every identity that's
basically unused, We use 90 days to start, you know?
Again, some people may want it to be longer.
We can have a big long discussion about how long
something has to be unused for before you think it's unused.
But what's neat about this is we can take every account, every
project, every subscription, and we can tell you in there like
what identities are unused. And when you actually click the
quarantine button, we don't actually delete those identities
at all. What we do is we basically short
circuit their permissions so that they can't use any of them
anymore. And why we do that is is again
back to history after years of doing this with customers.
What we discovered was people were scared to delete this stuff
because what happens is, is that maybe they have a a process that
runs every year and it does something or they have a
infrequently used device and they've used something in their
cloud to configure it. But if you delete that identity
and then you have to put it back, you don't know what
permissions it needs. You don't need what the don't
know what the identity was called.
Maybe that's connected to a resource policy so you can't put
it back the way it was. Maybe it had an access access
key, and I hope you didn't do this, but you hard coded the
access key in your code and now if you've deleted that key
material, you're going to have to generate a new one and then
you know, have somebody fix the code before the thing would work
yet. And so we had this scenario with
zombies where people just wouldn't delete them.
And you know, this is a a great demo environment.
We look at this, but we had customers that have 10s of
thousands of unused identities sitting in their cloud and they
won't delete any of them because of the sphere.
And we think this is a better way.
We can basically clamp them down and say you cannot do anything
with this identity. But if you do come to the point
that you need to and we see it try to wake up, it gets a deny
for the first time in seven months, send the team a message
saying do you want to reanimate the zombie?
You can reanimate it and the thing comes back to life with
exactly the same permissions it had, exactly the same access key
it had. All of those things are still in
town. So you know, I love the zombie
story. Again, curious what you guys
think about that. But it it really is a way to
kind of clamp down a lot of this risk pretty fast.
It's. In these environments, it's
super cool. I hope that instead of
reactivate, it just says reanimate zombie.
There's there's a there's my marketing for you on that.
I want to go back to a couple things.
You you you pointed out, you mentioned, and I wanna make sure
I heard it right. If I click protect to do
something, you're not actually do anything.
You you mentioned you're staging a change and that you're using
native infrastructure basically as code to stage that change.
Does that mean I can as an engineer look at that code and
inspect it and make sure everything looks OK?
The way I can double check it and have that level of
transparency it it's exactly true and we.
We did it this way again, we had a bunch of design part.
We've been working on this for, I don't know, nine months, maybe
a year now. And we've had all these design
partners all on the path with us that have been kind of helping
us with this. And what we found was the
editing. These parts of the cloud are
super sensitive, like SCPS at Amazon are a great way to break
something. You know if you deny everything,
all of a sudden you can't do anything in your whole cloud,
right? Or if you create a deny by any
GCP, it, it overrides everything.
So basically the customers are like, you know this is a super
sensitive thing for us. We don't want a third party
vendor like Sundry having direct access to going to change these
things. And some of them had really
strict policies that said, OK, all of our changes to this part
of the cloud must be checked into GitHub, they must be PR Ed
and then they must be deployed using some mechanism they had.
And so we set it up this way so that when you do that, you know,
set of pending changes, you can actually get this template, you
can check it into GitHub if you want, you can, you know have APR
on it, somebody can inspect every line of that code and then
go and deploy it into the cloud and make it active.
And so we separated the permissions of the product being
able to actually go in and make the changes versus automating
how that gets done for the customer to go do it.
And it was it was where all the design partners settled with a
good experience, right. You know, there's a few of them.
That said, I just want a button to press.
OK, well, you can automate the button and make it pressable if
you want. But for the people that wanted
those checks and balances, it was a great intermediary for
doing that. So, yeah, all right, let me show
you guys a couple other things. I'm going to, I'm going to skip
ahead here a little bit and I'm going to, I'm going to show what
it looks like when you get into one of those individual
services. And it's the first time, by the
way, we have light mode and dark.
Mode, which again you guys are. Thank you, thank you, thank you.
Dark mode should be the default everywhere.
And that is a hill. I will Zion.
You know Zion, Yeah, we had, we definitely have developers that
are in the same hill as you and then we have a few of our
support guys that like Light Mode, so it's a weird, you know.
So much easier on your eyes, especially at night.
You have this, you know nobody likes just layering light
screen. At least you know a dark.
Ray, can you notice? We can talk about this on this
podcast. You notice we snuck the purple
color into the cloud, which is Firewall.
Yeah, yeah, yeah. Yeah.
It's all about branding name somehow.
Yeah, exactly like so. Everybody uses.
There's certain services you can't turn off, right?
So it's nice to talk about unused services.
But then like if we go into EC2 as an example, every account's
probably going to use those and you know you'll have some set of
sensitive permissions with it. But when you look at an
individual account, we could actually find automatically the
identities that are using that. And so this is an exam.
This happens to be an AWS reserved SSO role that's using,
you know, in this particular case, one of those those
sensitive permissions. But you can actually look at
every service individually and see everything that is using
them versus you know what you know has access to it.
And so I think it's an interesting way you think about
that first screen with like 75 identities and then you come in
and you find out there's really only 5 using it or 10 using it.
You really are compressing that open space of of permissions
that you have very, very quickly.
So anyway, just another neat part of the product in in that
side. I know we've been looking at a
lot of AWS resources. I guess from a capability
standpoint, is it similar for both Azure and for GCP?
Are there differences in functionality?
There, there we tried to make it as close to the same experience
as possible in all three clouds. I will say there's this, and I
think we may have talked about this on the first podcast we
did. AWS and GCP are deny first
models, so when you put a deny anywhere's on an identity, it's
denied to do whatever that permission is.
No matter how many allows you give it, you can never override
that. Deny Azure is not that case.
Azure is an allow first model which you can put as many denies
into Azure as you want. But if there's one thing that
says rather through an inherited entitlement or a direct
entitlement, if it says that you can do it, then you can do it.
And so we had to change the experience just slightly for
Azure because unlike AWS and GCP where truly it was a centralized
control at the top that we just said, you know, clamp this down
and deny it, in Azure we had to actually do some fiddling with
the real policies that people were using to change them from
and allow to deny in that scenario.
But we were able to actually, again, infrastructures code's
amazing, we were able to actually write the state into
the the RBAC assignments that we were doing to keep it a similar
experience. It looks the same when you're
doing it, It feels the same to the end user, but under the
covers it's quite different what it's actually doing.
So anyway, always the things that you run into in in these.
What is it? OK, I'm gonna.
I I I'm just curious what does it take to set this up?
I just connect it similar to I guess other services where I
feed it my an admin credential, I'm assuming of of each of
these. We we deploy it with
infrastructures code as well. So in AWS we use cloud
formation, in the other two we use Terraform.
Again there's there's different ways of doing it.
What's interesting is, is that it kind of goes in in monitor
mode by default. So when you when you deploy
this, it's going to learn all the things about your cloud, how
big that space is between what's been granted sensitive
permissions and what's used at how many zombies you have, what
services you've used. And it does that using really
light permissions. Think of like security auditor
style permissions that can list and describe things but don't
have any ability to change anything.
Once you actually go live with this and now you've deployed
that, you know you've gone from that pending state into the
protection state. At that point the thing becomes
live and there are slight different permissions that
happen in the cloud at that point where the system actually
needs to be able to change some resources and stuff.
But they're still really light permissions.
They're not, you know, control the whole organization and
control the SCPS. They're just the light things
that do the permissions on demand work.
We have to turn these permissions on and off on an
individual exception basis. So it's pretty, it's pretty
neat. I've actually got an example
here we can show in AWS where once this has been set up like
and it's in its live mode so again you you've onboarded, it's
all done with infrastructures code.
It's a bit like watching paint dry.
It takes you know some period of time to go and do this but
you've deployed these if a developer's in doing something.
So this is an example. Here you see an AWS console and
you know somebody's editing a security group, so go back on
that network theme again and they were to edit one of these
rules. So they're going in and they
say, look, I want to create an an inbound rule and they want to
open up port 80 and port 22 or something.
When they actually go and click this to do it, they will
immediately get this deny response if they're not in that
exemption list, right. And so the thing's been
deployed. Someone has gone and deployed a
bunch of controls using, you know, their Cloud OPS account.
So it's in the protection mode. They get a message that looks
like this the first time that they do it.
But what happens in our system is immediately after that is
there becomes a request and this.
Like I said, this can come in Slack can come in, teams come in
e-mail however you want. But fundamentally what happens
is we detect you see my example user here.
Sneaky. Jeff I was honored for a second
there. I had.
I saw Jeff contest and then I'm sneaky Jeff.
What? Now you're sneaky Jeff trying to
get those bitcoins. That's right, they said.
You know him better than he knows himself.
Exactly. I so you know Sneaky Jeff's in
here, Sneaky Jeff gets denied. This goes to that team that's
responsible to approve these. They click approve it.
They can, you know document why this is approved and all these
things. And at that point, you know,
Stinky Jeff gets a message back and they can save this and
immediately it works. And it's again, we, we play a
little bit here in the demo to make this faster and speed it up
so that we don't have to log into AWS.
But that the reality of the situation is you go from being
denied to being allowed to do something in minutes.
It's it's literally from the time change and the slack
messages and the people clicking one minute later you have
permission. And it's this is the thing that
the design partners were super excited about.
You know, it's one thing to be able to take all of this risk
out, but it's another thing not to basically block the teams
from doing their work when they needed to get it done.
And so again, that was one of the biggest kind of epiphanies
in building this thing was it's not actually about, you know,
the cloud permissions firewall that's so important in that
default tonight. It's about enabling all of the
teams to keep running at speed and not getting in their way so.
So Sandra, I can imagine like one of the initial objections
you might have from a cloud team is like, well, if they only have
a native US cloud or only have AGCP cloud, couldn't they get by
with the tools that are provided within that cloud to kind of
achieve like you hear this from Amazon customers where it's like
we can use Access Analyzer. Is that like such a poor man's
solution to this problem that it's not really a good question?
It's, it's interesting. I actually think and sometimes I
think about it this way, Jim and I get this a lot in like talking
to customers, especially customers that have not gone
through the pain of trying this with Access Analyzer yet.
So they've seen Access analyzers marketing material or they've
seen sundry securities marketing material from before this point
in time. There's a a perfectionist view
that I want everything to be perfectly least privileged.
So what Access analyzer's doing, it's going back to every
permission that's ever been used by every divinity and you know
AWS 14,000 permissions and Azure 10,000 permissions.
I don't know the numbers exact, but it's it's high and it's
creating that perfect policy to put on that, that identity and
then you need to test that, right.
So if it's a real workload, you now need to test it.
You test it, then you get it to prod and then you do it all over
again and tomorrow there's a new identity, but you got to wait 30
days or 90 days for Access Analyzer to get there.
But I think in that early stages, even myself when we when
we founded Sunray, that's what I wanted.
I wanted the perfect outcome for every identity.
And I think I just maybe have the scars on my back now from so
many years of saying we got to do something a lot faster to get
to a lower risk much quicker. And then go back and apply that
aspect at a much more granular level to the things that are
really important, right. The the things that are really
that are really exposed. But I think the question is
still very valid that you're asking, right?
Like Access analyzer, the Sun Ray solution that we talked
about on the last podcast, whichever that's trying to do
this perfection thing, I think people want to do that.
I don't think we actually give our development teams enough
time to actually do it. You know what I mean?
Like, they're not gold to get their app out the door because
it's at least privileged, right? That doesn't make the money,
right. And so, you know,
vulnerabilities are a great example, right?
You got to patch your vulnerabilities, but you have to
do that because there's an audit team coming behind you to say
are they patched, right. And we all know we probably
have, you know, some, you know, backlog of those that we have to
work at. So what's the chances you're
going to get to this privilege thing in that scenario?
And so I think, again, your point's valid.
I actually think there's a there's a a reason to do least
privilege. I just don't think people can
execute it and operationalize it fast enough.
So. Yeah, that that's a great
response. You know, I'm kind of trying to
picture this in my head. Like, OK, let's say we take this
permissions firewall and we want to have it work in our AWS cloud
as well as our GCP cloud. Do I kind of like, install
something? How?
How exactly does it work? Where does Where does it go?
Yeah, there's two. And again in both clouds,
slightly different deployment, but it's the same process.
Basically in the initial monitoring mode you're putting
in those security Otter permissions for the sun res, SAS
to look at your cloud. You know in AWS if you're
familiar with these things, you would actually be familiar with
like the the manage policy for security otters, pretty light.
In GCP it's a very similar scenario where it's just looking
at like list, describe permissions, list the service
accounts that are there, list the the roles that they've been
assigned like things like that and then what happens after
that. So that's the first deploy.
But we can see your whole cloud from that and IT and you know it
takes 10 minutes to deploy it maybe in a really big cloud with
like you know, 5 or 600 accounts.
It may take a day to to look backwards in time, 90 days.
So we can get history, but after that day we have that
visibility. Then you actually protect stuff
and you click deploy again. That's another piece of this
infrastructure's code that you're going to go run and put
those controls in place. So you know, you ask like where
does it go? Well, it kind of lives in the
cloud with the rest of your workloads, right.
You know, it becomes another identity with a bunch of
permissions on it, hopefully not too sensitive, right.
That's actually monitoring your cloud.
It's it's all cloud native. You know, there's no, as I say,
no man in the middle, no proxies, no weird boxes.
It's it's a great way to do it. So and no vulnerabilities to
patch 'cause there's no there's no running workloads there, so
even better for you. Yeah, You brought up the, the
point about like no proxy etcetera.
So this is just cloud, right? I mean there is no version for
the on Prem because I would love to have something like this for
on Prem. I'm sure I'm not the first one
who's ever wanted that. Assuming I'm right and it's not
for on Prem, why doesn't anybody built one for on Prem?
So on Prem I and we talked a little bit about this in the
prep call and we did this and I I had this you know whatever
vision like why did Sandy build a company in cloud?
Cloud was this interesting enabler for the first time that
allowed us to see all of the things that people were building
and it was like having a real time CMDB running all the time.
So why is it? Well, in order for Amazon or
Google to charge you for that Lambda function or that virtual
machine or that Bigquery table, they had to have an audit record
that it ran and it had to be on the bill at the end of the
month. And so Cloud gave us this first
time where we could truly see all of the workloads.
There was APIs to find them. We could see all of the activity
that they were doing. Over the last five years, I've
realized not everything is audited and there are some
exceptions to that rule. But the reality is most of it
is. And on Prem and I spent years in
the security information management, SIM space, you know,
doing these types of things, man, CMDS were always so out of
date. You know what I mean?
Like, it's like, yeah, this is what we believe it looks like.
And then tomorrow it was out of date.
And you know, you had the, the, the admin that had the extra
rack beside the rack that had his special gear in it.
And it was like it was so hard to find everything and even
capture the logs all in the central spot that people just
couldn't do it right. It was just too out of control.
The way that you built your VM was different than how the other
guy built his SAP. And you know, how does this
stuff all work? But when you deploy it all in
Amazon or GCP, you know those things are there, we can finally
get to them. And so again, I think there's a
huge benefit to possibly doing this on Prem.
I don't know that that's going to happen anytime soon because
it's just too much the Wild West, the cloud providers gave
us this centralized point with a centralized set of APIs that
could be predictable and allowed us to do this for the first
time. It's interesting.
In GCP, this deny function that we talked about, it was only
released like last year. They didn't even have that
functionality a year ago, so you couldn't have even built the
solution a year ago in GCP. Wow.
So it's it's interesting that they're they're accelerating
this way. Where you'd have to come up with
some kind of like Rube Goldberg type solution to kind of,
because it sounds like that's what you did in Azure.
It the the Azure one and you know somebody would get mad at
me if I said it was a Rube Goldberg machine that we built
for Azure. It's not, it's very it's
programmatic and it does it. But there is definitely there
were some struggles we had in the model in Azure because of
how it is where again up we don't have to demo up anymore.
I'm not showing you guys this, but when you go into the the
Azure and you're looking at a single subscription or single
management group. There's an extra line on it that
says these identities we can't control because at this point in
the tree, because above this point in the tree, they've been
granted permissions that we won't control At this point,
they're just inherited and because it's allow first, they
have access And so if you want to control them, you have to go
higher in the tree with Sunri to control those levels and there's
just no way around that. And it you know, it's because of
how their model works. So anyway, that's why as you
say, it's not a Rube Goldberg machine, but there's definitely
some differences in how that code executes compared to that
the AWS and GCP ones. Yeah, I was going to say I hope
it didn't come off that I said it that way, but I guess that's
exactly who's didn't mean to say it that way.
I just thought I should say, OK, so imagine the scenario, you got
a booth, you're at RSA or you're you're at AWS Reinforce or
you're at Identiverse. I'd love to see you guys go to
Identiverse, but you have a booth.
Now, who in the organization do you want to stop at that booth?
I mean, who buys? Who's going to buy this product?
Is it the person who says I need this to make my job easier?
Is it the Sisso who comes by and says I need this to make my
environment more secure? Is it the app developer who says
I need something so that I can have the security people get
what they want? Like who?
Who's the ideal person to come by and then who usually does
come by? Yeah, that's, yeah, those are
the great questions. You know the target for us is
and they have different names. It could be the Cloud OPS
engineer, Cloud infrastructure engineer, Cloud Operations
manager, It could be, it could be the cloud center of excellent
lead. I don't know.
It's the person that owns cloud for the whole company.
So if you have 50 teams building, somebody owns the GCP
infrastructure for those fifty teams and they're the ones that
set the golden rules for how everything rolls out.
They're the people that struggle with this and want to put the
controls in but are worried about breaking things, right.
They they want to put the SCP in to block it or they want to put
the deny binding in to block it. They're worried they're going to
break it. So we're they're our perfect
customer to talk to because they feel the pain.
They see how the sols look quick, they love it.
That said, they may not know our system exists and they certainly
may not go to Identiverse, right.
It's more likely at Identiverse you end up with the CISO or the
security lead for IM or something and they're trying to
get things to least privilege and they're talking that way.
We want to talk to those people too because we they may not even
know that much about how cloud works, but they know they have a
big problem, right. And so rather it's a CISO or the
head of Identity or whoever it is that knows they have a
problem around least privilege. We want to talk to them too,
because they're a big help. The you talked about the app
developer, it's interesting to tell them that, But they're not
the person that can procure and buy the solution.
They're they at best would be a sponsor to talk to the next
level. They may find it interesting,
but they don't even have enough power in their accounts to
deploy it. So they're probably not the
right target. Right.
So it's the the person responsible for the cloud or the
person, person or group responsible for security.
They see a demo. When, when does the epiphany
happen that, oh, I need, I need. There's there's there's two
epiphanies that happen which are super interesting right.
You know one is when they see the demo with the permissions on
demand thing, people love that it's like all my land we can we
can grab this stuff back very quickly.
The other one that I find so intriguing is the zombie one,
which is why I gravitate towards it, 'cause people just know that
they have these things and have no clue how they're gonna clean
them up. If they're scared to death to
leave them and they're like, seriously, we could turn those
all off and then turn them back on.
It's like, yeah, and people are like.
Wow, that's great. So those are the epiphanies for
the person walking up to the booth or that first call.
For customers that have been trying to do this, though for a
period of time, this is a relief for them.
They're like only land I I can focus on the right stuff.
I don't have to try to do this for 100,000 identities.
I can get this thing in place and and go about my my work and
those for those people. The epiphany comes more on that
sensitive permission clamp down that happens.
So I'm gonna make the first official feature request.
I want to see either on the website or maybe as part of like
the interface panel, some number in like a bloody font, this
number of zombies killed or something like that, right?
And it just increments up and up over time.
So yeah, some some free feature advice that I'm that I'm willing
to part with. I I love it.
I don't have a clue if I'll ever get that by our design team, but
I love the idea. Well, it's kind of purple 'ser
Egg. Yeah, that's right, purple.
An Easter egg for every time you, like kill a zombie account,
you get to go into a video game world and start killing a
zombie. Still a zombies, exactly.
So I think this sounds great. I love the demo.
You know, we got to see the demo.
Hopefully everybody else got to visualize it in their head.
But for people who want to try this out, Jeff gave a mention of
you know, where you can go to actually visually see the demo,
which I think was sundry.co/idac.
But if someone wants to actually try this out, what's the options
that are available for them? Yeah, there's this and this is
also a fairly large change for Sunroof Security, the company
we're doing basically 14 day kind of free trials of this
thing. You can just try it and if you
like it that's great and where you've actually put all of the
pricing for it on the website cause the concern with some of
these cloud tools are you go is like I don't even know if I can
afford this for my, you know my world and I don't want to try it
if I can't afford it, right. So we've we've opened all of
that up. So again bit of a different
world for us that we're trying but we think that kind of open
pricing model, 14 day free trials just go and try it, see
if it works for you. The great thing about this is,
is that you actually can figure out in 14 days if it works for
you. You know, you can get that
visibility, you can pick a development account, you can put
the controls in, you can try the PODO.
It rather works or it doesn't for you and your organization.
Our previous product was a large, you know, lots of
visibility, lots of things that you could fix.
But to get the full aspect of how you're going to
operationalize that took a lot longer.
And so it was a thing where it really was a bit of an
enterprise sale where this is a small team can run this.
You know, maybe you only have 10 AWS accounts, but it actually
makes perfect sense for. You so so Jim was talking
earlier about conferences, are you guys going to be at anything
coming up maybe like RSA or or AWS?
Yeah, we. So again a few of our people
will be at RSA. The big one for us is AWS
Reinforce, which is a fun AWS security only conference, right.
If you go to the the Reinvent Conference in Vegas, it has you
know everything under the sun from satellites to whatever the
security conference is. Just how do you secure a cloud?
Great sessions, great speakers. We got a booth there, couple
speaking slots which are which are pretty neat.
So that's a fun one for us. We love that conference.
It's a great conference. Few people at RSAI think we're
doing the Gartner. I am one at the end of the year
which I think you guys go to. So it's lots of places to see us
along the path. So I can come up to a booth and
you'll have people that can kind of walk through this demo, or I
can go online sundry.co Yep slash IDAC to to learn more
about. IDAC exactly, and I believe I'm
going to say if see if the website's ahead of me or not.
I believe there's a click through demo people can try to
which is not dissimilar for what I showed you guys.
So I I think there's a click through demo there that people
can click on and and see how it works.
It's really. Impressive.
Definitely. Want to encourage people, and
thank you for taking the time to kind of walk us through this.
It helped seeing anything, and hopefully people were able to
visualize and sort of their mind's eye as we walk through
it. But definitely encourage people
to go check it out. I love the idea of not only just
taking the day you're collecting, but doing something
with it. And I think this is an area that
a lot of people should be looking at.
It's OK, great. We've got visibility.
Guess what, No more excuses. Now you got to do something
about it. So here's an easy button,
literally right, to help with that.
So thank you for that. I want to wrap up with something
totally unrelated to identity. Or maybe it is, I don't know.
But we want to talk about fishing.
We were talking about you're going on a fishing trip soon and
I gave you kind of a a list of fishing related questions and
you were like everything except that one.
That's why I won't ask that one. So I'll ask and said if you
could go fishing in anybody of water in the world, where would
it be and why? Look, I've been, I've been
thinking about this question possibly for years.
And I if I was gonna do it, anybody in water anywhere in the
world, I would go, probably the fjords in Norway.
And I would spend some great time there.
And I would go because it would be beautiful, it would be
unique, and I would have a great time regardless if I caught a
fish or not. And so if I could go anywhere,
that's the one I would. Pick I'm with you right there.
I don't even think I would go fishing.
I would just sit in the boat and just stare up at the giant, you
know, the the scenery and stuff like that.
Yeah, I'm not much of A fisherman, so this is really out
of question for me. And to be fair, the question I
was that was in the original list was like a gadget related
question. So I could definitely come up
with some of that. Jim, if you could go fishing
anybody of water in the world, where would it be and why?
So much of A fisherman, but a couple thoughts came to my head.
So one was, if you haven't seen the show River Monsters, which I
think was on Netflix for a while.
Such a cool show, this guy, he's like, he's so entertaining and
then he goes fishing for these monster fish all over the world,
like he'll be in the the Amazon, like fishing for these fish and
they come out and they look like dinosaurs, right?
So great show. It's reminded me of a story that
I just heard. So Denise told me that one time
her, her father and his best friend went for a fishing
weekend. And instead of fishing, they got
so drunk and they never went fishing.
So what did they do? They went to the grocery store,
bought a bunch of fish, unwrapped it and brought it home
just so they didn't get in trouble that all they did was
spend the whole weekend drinking.
That's a great. I mean, I would do that.
That's totally legit. Very creative, yeah.
Unrelated, but I had a roommate when I was growing up, and I
think probably in the early 20s, late teens, and he was trying to
impress a girl. So he ordered Italian and
Italian got delivered, and they took everything out of boxes and
put it on plates and pretended that he had cooked it all.
Same kind of idea, Chad, if you're out there, you know who
I'm talking to. And she was probably like all
this kind of taste. This is this is just like Olive.
Garden. Yeah.
Look, you know, we're young, We're, you know, trying to
figure things out and whatever you got to do to get by, I
guess. All right.
This has been a great conversation.
Sandy, thank you so much for taking the time.
Thank you for coming back. Hopefully, you'll come back in
the future with other cool announcements you guys might
have. Definitely want to encourage
people, go check out the Cloud Permission Firewall.
It's at sunree.co slash IDACSONRA, i.co/IDAC.
We'll have links in our show notes so people could check it
out there, our website, etcetera, all that kind of good
stuff. And of course, you can follow
Jim and I on LinkedIn, We're on Twitter, Mastodon at IDAC
Podcast, we're on YouTube, we're on the web, idacpodcast.com.
And with that, we'll go ahead and leave it for this week.
Thanks again, Sandy, and we'll talk with everyone else in the
next one. Thank you guys.
You've been listening to Identity at the center.
We hope you've enjoyed the show. Make sure to like, rate and
review and we'll be back soon. But in the meantime, hit the
website at identity@thecenter.com.
See you next time on Identity at the center.