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.