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