Security Unfiltered
Security Unfiltered
Unlocking Cloud Security: Insights and Innovations with Sandy Bird
Are your cloud environments secure, or are they silently exposing you to threats? In this gripping episode, we sit down with security industry giant Sandy Bird from Sonrai Security. Sandy draws from his rich 20-year career, from founding Q1 Labs to his pivotal role as CTO of IBM's security division, to share invaluable insights. We uncover the evolution of cloud security, focusing on the intricate challenges of AWS IAM (Identity and Access Management). Sandy discusses how Sonrai Security is leading the way in transforming IAM with advanced analytics, helping teams effectively manage complex AWS privileges.
Machine identities in cloud environments can be ticking time bombs. Sandy breaks down how developers might unintentionally create vulnerabilities that bypass traditional firewalls, making systems susceptible to external threats. With startling statistics on the number of forgotten cloud identities, we explore the enormous task of tracking these identities and the steep learning curve faced by new IAM security professionals. The conversation also covers the often non-intuitive nature of AWS permissions and API calls, adding another layer of complexity to security management.
AWS environments are unique and bespoke, posing significant challenges. We discuss the intricacies of AWS certifications, the numerous traps in exam questions, and the importance of a centralized permissions firewall that offers guardrails while allowing developer freedom. Sandy introduces the idea of a 14-day trial for a cloud permissions firewall in a monitor-only mode, providing a risk-free opportunity to understand its benefits. Tune in to discover how innovative solutions are shaping the future of cloud security and why a permissions firewall could be a game-changer for your secure cloud operations.
Free Trial: https://sonraisecurity.com/trial/
Sonrai Security Website: https://sonraisecurity.com/
LinkedIn: https://www.linkedin.com/in/sandy-bird-835b5576/
Sonrai prides themselves on being able to reveal every over-privileged identity and all paths
Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.
Follow the Podcast on Social Media!
Instagram: https://www.instagram.com/secunfpodcast/
Twitter: https://twitter.com/SecUnfPodcast
Patreon: https://www.patreon.com/SecurityUnfilteredPodcast
YouTube: https://www.youtube.com/@securityunfilteredpodcast
TikTok: Not today China! Not today
How's it going? Everyone? This is another Security Unfiltered episode. So today we actually have a really special guest. We have Sandy Burdon from Sonri Security. Sonri actually sponsored this episode, but that doesn't mean that they gave me any questions or anything like that or, you know, told me where to bring the conversation. This is a natural free-form conversation, like everyone is used to. We dive into Sandy's background of how he got into IT and then we talk about some of the really fantastic, interesting things that Sonri Security is doing in the cloud IEM space. That's really revolutionizing the game. So stay tuned, pay attention. It's really some important stuff that they're doing. That is really revolutionizing how we will be uh, you know securing the cloud in the coming years and in the future. So thanks everyone. I hope you enjoy this episode. How's it going, sandy? It's a great to finally get you on the podcast. We've been talking for maybe five or maybe longer, maybe longer than six months at this point, but I actually don't know your background or anything.
Speaker 2:Thanks for having me, joe. My background is long, yeah. Yeah, I think I started in something to do with security probably 20 years ago and I founded a company called Q1 Labs which was a SIM security intelligence company. Although it never starts that way, you know paths of starting companies start in one direction and then change four times before you hit the end of them, and I just love the analytics part of it, right, digging through logs, finding patterns, all those things as part of the history of that company.
Speaker 2:It was acquired by IBM and so I spent time after that acquisition being the CTO of the security division at IBM, as they were standing up their first security division, so it was really the first part of that for them. What was interesting about that was we took a lot of, we acquired some companies, we took a lot of other security assets that they had, their identity products, things like that brought them into the division, and what it gave me was this interesting view of all the parts of security, right, application security, with the old app scan I shouldn't call it old, I'm not supposed to say that, anyway, the app scan part of that portfolio. We had, you know, very modern mobile MDM technologies for security. We had the curator platform for security intelligence. We had the old ISS Again, I'm using old, I shouldn't use those words we had the ISS assets for the IPSs that were in line and things, and so we had all of the parts of security. And so it was interesting to learn how all this worked.
Speaker 2:But I got really excited as we were kind of looking at cloud and how these new dev teams did everything. So they, you know, they built the databases, they built the runtime, they built the identities that use them, they built the whole workload and they deployed it with code. And I looked at this kind of specialization that we were doing in security, where everybody was a specialist in IAM or they were a specialist in, you know, database security or whatever it was, and said these new teams don't work that way. They are generalists at all of the parts and they're being asked to not only deploy the stuff but secure it. And so we thought there had to be a better way to do security in the cloud and we sort of took a.
Speaker 2:We originally started in data. That again back to history, sunri actually means data in Irish. So it's a cool thing for your, for your listeners, to think through, and so it's a cool thing for your listeners to think through. And there's not many domains left, so if you're going to register a company, it's really hard to have like datacom.
Speaker 1:That one's taken, yeah, and you have to pay an insane amount for that sort of thing.
Speaker 2:For that sort of thing. So, anyway, Sunree sort of worked for us and as we were looking at the data in cloud, we're like, well, the way that this is accessed is through all these crazy IAM things, and I know you're very familiar with AWS, and so the complexity in that model, with resource policies and then key management policies and then the IAM policies, the boundary conditions it's just crazy complex and so we build a lot of analytics around that. So that was my background. I really, you know, thought that we could do this perfection thing. I was like we have all the log data because the cloud providers have a bill, so it has to be logged. We have these IAM policies which we can look at. We could make them perfect. And so that was my theory when we started this company was we're going to have perfect least privilege for the first time ever? Yeah, I might have been a little wrong, but anyway it was a good, it was a good theory.
Speaker 1:So yeah, you know you bring up the complexity of AWS privileges, right of AWS privileges, right. It takes me back to when I was studying for the AWS Security Specialist Cert and I think I spent 90% of the three months that I studied for that cert. I think I spent 90% of it on just IAM and IAM-related things, right, because it's not very obvious. They're not very obvious issues, so it's not telling obvious. They're not very obvious issues, so it's not telling you. Like even when you get an error in in aws, typically the error is not descriptive enough to tell you go to this account in iam and adjust this from. Like it doesn't tell you any of that. It does not.
Speaker 1:And you have to think of it a totally different way. Like you have to actually think about it in reverse, and that's what a lot of people like mess up, you know they don't think about it in reverse. You have to actually think about it in reverse and say what do I want to do? Okay, what does that policy look like? Where does that policy need to live? Who needs to access it? Does it need to transform into something else? Like those are the questions that you need to go down and it is. It's so painful. You know as someone that, as someone that has spent the last seven years in aws right, it hasn't gotten any easier, it's gotten significantly more difficult and, uh, you know it feels like. It feels like they just expect you to keep up, they expect you to understand what's going on the.
Speaker 2:There's this lovely diagram that AWS has that explains the tree structure of what's allowed versus denied and it starts at the top with the SCPs and there's a bunch of decisions and it comes down into the. You know the resource policies and you know, is there an explicit deny? And it keeps going. You know it keeps going down and there's this one point in the tree where it does this weird split thing that says is the principal identity inside the account or outside the account? And then the tree like changes completely. And then in the middle of that tree there's this thing but is it an IAM resource or a key resource? Cause it's different if it's those versus the rest of them.
Speaker 2:You're like, who's supposed to know this stuff? You know, as you go through it and we spent again when we were building um and you know this Joe, like we kind of have two products at Sunray right, we built this CIM product, cloud infrastructure and title ones management project, and now we're doing this cloud permissions firewall thing. We built the first product like trying to understand like every single way that these things are allowed or denied through all this to recommend. You know things was was crazy and you know it's hard.
Speaker 2:You're trying to explain it to people and there we have customers that are like large banks and they really care. They have triple negatives in their policy statements and they, like, want us to be able to say you know, does this thing have access or not? Based on those triple negatives? Right, but you know, for normal humans looking at these policies, they're like that's way beyond anything they could ever comprehend. It's crazy what AWS has done. Now, that said, there's some really powerful stuff in there and you can do some amazing things with it, but you have to know it.
Speaker 1:Yeah, it's a shame that it is so useful. It's a shame that it is so useful. It's a shame that AWS is so useful. You know they're the thousand pound gorilla in the cage, right. It's like, oh, you're going to the cloud, well, you're obviously going AWS, right. And then when you get the outliers that are like, oh no, we're going all in on Azure. You know it's interesting. It comes to my mind. You know you don't really hear about people saying, oh, we're going half Azure, half AWS. You just don't really hear that. Whenever you hear Azure, it is always we are going 100% Azure, like we're shutting down data centers and stuff. And that's a really interesting business model. I understand it from Microsoft's point. They want more people to use more of their resources and whatnot. But at least AWS gives you the flexibility to say I'm going to use AWS and Azure and GCP All of it's going to be tied together with this IAM thing when it's all going to work.
Speaker 2:And again there's other. We could spend a lot of time between AWS and Azure talking about identity models, because they're so completely and utterly different than one another. You also have this kind of interesting. I mean there's certain industries that just won't use AWS Like, retail is really allergic to AWS, right. They don't want to use it for obvious reasons, and so you have, from us, as a company perspective, we still have to spend a lot of time in an Azure understanding their models.
Speaker 2:I love this one, though. This is how I summarize them to people when they ask what's the difference between the AWS identity model and the Azure one. And I always say AWS is deny first. If there's a deny, it always wins right, and so it's quite predictable when you're building their models. If you can stick the deny in there, then the thing will be denied, and so if you're looking for centralized controls, it's actually quite helpful to have that. The Azure model is different. The Azure models allow first, so you can have a thousand denies, but if you have one allow, you're allowed to do it, and because of the hierarchy and the trees that they have with the management groups and stuff, it's really easy to inherit something from above allowing you to do it, that you don't even see at the scope that you can see. You know again. So it's a different set of problems. It's not that they both have their challenges, but there's a there's certainly a different set of problems in Azure.
Speaker 1:So yeah, with AWS, I think they call it an explicit deny where, unless you explicitly allow it, it is denied, it is denied.
Speaker 2:Yeah, yeah, exactly. I love how they use those words, though. But then you have these weird like resource policies where things from outside your account can get in and do stuff, but scps don't control those, so they're like exempt from that explicit deny. Like it's a really weird. There's these kind of weird rules to it when you actually look under the covers you just can't go down those rabbit holes yeah, exactly, yeah don't look at that.
Speaker 1:It's uh, you know, it's always. That's always probably the most complicated part as a cloud. Anything these days is the permissions. I guess not as a developer, right, because typically companies just set up developers to have access to whatever they need and they call it done right, like they don't even look at it again. But from an IAM perspective. You know, I'm coming at this, I'm coming at the cloud from an IAM background, an on-prem IAM background, right? So I'm used to, you know, really powerful tools and really bad tools that you know either do their jobs really well or really poorly that impact how the entire organization operates. Right. And moving from that into the cloud, it's like I had to relearn everything and the solutions with the exception of Sonri, the solutions typically didn't even make it any easier. It was like, oh okay, this is a different UI to view the same exact stuff. I am stuck in the exact same spot Like thank you.
Speaker 2:Yeah, it's, it's really complicated. The other thing that I found so it's interesting that you came from this enterprise background which, again, when I was at IBM, I had a lot of these enterprise tools which I would agree Some of them are there's good ones and there's bad ones on that side, as there is never that. What's was really interesting, coming to the cloud for me and looking at the identity, was this in enterprise and I use this example so we had labs at IBM that you know did development, and so they were like five boundary firewalls away from the internet. Like no matter what you did in that zone, you could never really expose anything to the outside world because there were so many boundary firewalls that you had to get so many tickets requested and approved through that. You just couldn't do that.
Speaker 2:When I moved to cloud, what I found was super, super interesting was we were allowing these developers to build machine identities, the same thing they were doing in the lab, but those machine identities had access to these cloud and I'm going to use the word identity loosely because resource policies aren't really identities but they expose principles in and out of these accounts and all of a sudden, the work the developer was doing was one step away from the internet and in many cases, could not be controlled with a firewall rule right, because it was using a native call into an API that was public and there was no way. As you know, with all these different Amazon services I think there's well over 300 now it's insane how many Amazon services there are. Like some of them you can put some pretty stringent IP restrictions on, but other ones you can't, and so you know it seemed dangerous. You know, you looked at it. You're like, wow, we're really going to let developers, you know, break code and build policies and do these things and expose the lab to the outside world. But it's how we build today and you know we have to. We have to think in our own mindset that that's normal, that's, that's what we're trying to protect. But the machine identities are just as much of the identity problem now versus the human side, right, like I was telling you the statistic. Yesterday we were prepping for this. I said we did this kind of data survey, which was neat, and it said like 61% of the identities in the average cloud if you've been there for about five years were unused. So it's a big number and, depending on if you're looking at big customers, small customers, that number changes. Sometimes it's higher, as much as 80, and sometimes it's lower. But what was interesting about it was the human aspect of that was nowhere near the biggest part of it, like only 12% of that 61% was humans. The other part of it 88% of it was actually machine identities that had just been left there, like our SEs like to call them cyber litter.
Speaker 2:You know, you built the workload. It didn't work, but you left the identity around. You build a test Lambda function. You wired it up, you tried it, it didn't work. You left it there. You built the workload. You built version two of the workload. You left the identities for version one behind. And so I think, coming from enterprise, we had a reasonable person, lever, mover, joiner process and I think that translated into the clouds through single sign-on and directory syncs and all these things. In enterprise the machine identities couldn't do as much damage. Right, they were in a lab, buried between under five fire, it wouldn't matter. But now you look at that same environment and all of those identities are sitting out there with cloud permissions that are real. They're live fire at that point and we just don't have the processes in place to clean that stuff up, yet yeah, it's interesting that you bring up the kind of the process.
Speaker 1:Right of any DevOps team is they build an app. That app needs a whole bunch of different identities and roles and everything else assigned to it. Right? Five years go by, version two of this app is coming out and they typically don't reuse any of the stuff that they just built. Sometimes they even need an entirely new AWS account and see AWS naming conventions. It's called AWS account, but then everyone thinks it's a user ID.
Speaker 1:It's not it's just a separate billing account, you know, but but they're leaving everything behind, which increases the attack surface, you know, significantly, right, because really, in all of our tools tools if an attacker were to get in and use one of those dormant identities, right, that hasn't been used in a couple years, there's not really any way for me to sit there and identify it. I might be able to identify it at the end of the month if I, if I'm doing access review, like I should, right, which I try to steer away from, because that takes all of my time, a lot of time. Yeah, uh, yeah, I mean, you basically need a whole other team to do that sort of thing. Yeah, um, but, like a lot of people, I feel like they miss that point, you know, and they're wondering oh, how can this environment bloom to that much? It should always be pretty manageable.
Speaker 1:Aws will probably argue well, it should all be in code, you should be using Terraform, and when you use Terraform, you should just tear it down and it'll tear everything down. Well, one, it doesn't always tear everything down. Okay, you have to understand what you're looking at. You know, the problem with the complexity of the cloud, of where we're at right now is that it is so complex that someone coming into this role with the responsibility of you know IAM security in the cloud. If you don't have massive amounts of experience, you're going to be underwater for probably two years. I mean, that's just the brute reality. You're not going to feel like you're on top of anything for a while and companies don't have that time to spare. So they need more experienced people or they need a really powerful tool behind it to where someone can step into it day one and, you know, really pick it up and have a very good understanding of the environment.
Speaker 2:Yeah, and this, as you say, you know this learning process for the two years. You know one of the things AWS does in a lot of places is that the permissions versus the API call you're making are non-obvious right. Permissions versus the API call you're making are non-obvious right. You're making a call to say, I don't know, add a permission set in SSO or something like that, and you find out that you know you need attached role policy in this and you don't really understand. So you're like, well, it fails if I don't have this, but it works if I do so I'm just going to put them in and you put them in. If I do so, I'm just going to put them in and you put them in. But then you realize that that thing that you've just put into whatever workload you're using to do this work if you don't constrain those with. You know what the role you're attaching or you know what is going to be attached to or something. You don't have some constraint around there. You're leaving these wide open, like the ability for that attacker, as you say, to get a hold of this thing.
Speaker 2:They can now kind of privilege escalate across the board, rather the identity that they have they can attach a role policy to or something else that they've. You know they got some low level identity in some other spot. Well, now they can attach to that too and change its policies, and there's so many examples of that. In AWS, I think, there's whatever. There is 12,000 or 13,000 permissions in there. That in AWS, I think there's whatever. There is 12,000 or 13,000 permissions in there, there's all kinds of them that are non-obvious, that you know. If you're going to call this API, you need these other ones, and if those other ones are not constrained properly, they allow for these weird privilege escalation attacks.
Speaker 1:Yeah, you know it's interesting that no one else has really come up with a solution. You know that kind of shows all of this in an easily consumable format. As someone that has dealt with very complex tools before, especially in the IAM space, I feel like the on-premise enterprise IAM space has some of the most complex tools in all of security, which is interesting. You know, when I first got into security my very first role, the hiring manager, who I'm still very good friends with to this day he told me to you know, go pick up this privileged access management solution. It's a solution that I don't like and I refuse to work at a company that has this solution. Like that's how bad of an impression it left on me. And I won't name them. Obviously I don't feel like getting sued today, but you know he told me hey, you know we need someone to lead this solution. Pick it up, it's going to take you a long time to learn it, but if you learn it it's going to be really valuable, because there's no other solution in security that is going to be as complex as this. So if you just start with the hardest thing, everything else is going to feel easy, and I was like man, this guy is full of it. You know like he's just trying to convince me to do this thing. He knows how my head works, you know and this and that, and I mean sure enough, you know and it's interesting the opportunities that that tool gave me down the line. You know, opportunities that I wouldn't have gotten otherwise right, and I, of course, I pivoted away from that tool as soon as I possibly could. Um, you know it, it kind of like cracks open your mind a little bit, right, when you're spending eight hours a day, 10 hours a day, maybe even 12 hours a day in a tool's UI and you're like I have to go through three different, entirely separate places just to make sure that this is configured correctly, you really figure out the inefficiencies in a UI right, and so it's a very fine balance between having a tool that is powerful and having a tool that's powerful that's easy to pick up, and that was one of the things when I was playing around with the permissions firewall that I actually really liked.
Speaker 1:I could come into it as someone that's brand new and after five minutes of looking at it I can really get a very good understanding of what's going on right and that's extremely important to me. I've talked about that before on the podcast. So I'm not just trying to like butter up sonar, that isn't my goal. But as an end user, I'm always looking at that. I mean even at the other technologies, that I'm always looking at that. I mean even, you know, at the other technologies that I'm using today. I am looking at that as a overall perspective of that tool. Is it going to take me five minutes to find it or is it going to take me 30 minutes to find it? Because if it takes me 30 minutes, I'm probably frustrated at the 15 minute mark, right, and I'm pushing through to 30 to get it done, and that's a huge difference.
Speaker 2:We and this is again, as I say, all these companies, as even in my past are never a straight line Right. They don't. They don't do that, and so we. You know I'm an analytics guy, so you typically want to build these platforms that you can ask it any question and it can give you any answer. But when you do that, inherently you make a very complicated query model because you have to be able to ask any question.
Speaker 2:You know, we spent a lot of times making the existing Kim product easier to use and you know it just finds the identity and generates a policy for it that's least privileged and puts it in JIRA for you and you ask the developer to go do it, and so you spend all this time to make this flow easier. But even after doing all that, if we look at that Kim product with all those least privileged policies, when we measured the customers, first of all, they weren't fixing anything. And you ask, why aren't you fixing anything? And it's very quick to them to say, great, you've given the developer the least privileged policy, but the reality is they still have to take and put that into however they deploy that policy. Okay, let's lift it and put it in Terraform, as you say, right. And then they have to test it in development, and then they have to test it in UAT, and then a whole bunch of people have to sign off on it and then it will go to production and that whole process. You know, we we use numbers like that's 30 minutes of time to do that. It's probably way more than 30 minutes of time, but let's pretend it's 30 minutes, right. But then you multiply that by think about the number of these workload identities 10,000 of them 30 minutes times 10,000 is an unsolvable human problem. You don't have a staff to do this, and I think that was one of the biggest mistakes kind of I made coming in, because I, as you said earlier, we can finally build perfect least privilege. We have all of the logs, logs, we have all the policies. Let's make them perfect. But after you've been in cloud for five years, you drop one of these solutions on up. You can't do it, and so the the premise for the cloud permissions firewall was really in some ways being run over by that pattern and having the tire tracks on my back saying we have to create something that goes in. It analyzes everything that is needed, it very quickly generates very complex SCPs and uses ABAC access and all these weird things to create the good state. That won't break anything, but you can press the button safely. But even if you did that, that's a great solution, but it doesn't help you. On day two, you've locked everything down.
Speaker 2:Now, day two, you know, joe builds a brand new version two of the app comes out, version two, and it has a whole bunch of new identity and some of them need sensitive permissions, right, and so we had to have this. We call permissions on demand, where you can, you know, bump into a wall and it gets denied and it sends you a Slack message or Teams message or whatever. The approver presses the button to approve it. And Slack message or Teams message or whatever, the approver presses the button to approve it and now you have access to it. And so it's this really simple way to get access to these very sensitive permissions. And you know we can go down a lot of paths on that. We. You know customers will be like oh my land, I need to put this in all of your identity tools, right, I need to take it forward in service now, and then that has to be recorded in SailPoint and all these crazy things and you're like actually I don't think so, because you already put that in your cloud. It already has EC2 star.
Speaker 2:We didn't do that. You did that and you already approved it somehow. I don't know how you did it, but it got there. All we're saying is that you probably shouldn't be able to create VPCs if you've never created one before in the last five years. Let's just take that away Again. Making this kind of easier to use solution was a goal of this. To say, let's get teams to actually fix the 10,000 identity problem. Yeah, it's not, and again, I will be the first one to admit I get these purists on these calls, but that's not a perfect least privilege. It's only doing the most sensitive permissions. Mike, I agree, but you have 10,000 problems you have to fix and if we try to make them perfect, we'll never get there.
Speaker 1:Right, so there's a balance to it. That 30 minute estimate is probably generous, even you know, because when you factor in all the meetings, all the calls, the change management board.
Speaker 1:I mean, I'll spend an hour on a change management call just waiting for my name to be called and it's, you know, a quick, easy, simple task. I would have completed it within this hour. Those are the things that I feel like a lot of people don't really understand. You know they don't. They don't put that into context and when you're younger in your career and you're going through it, you don't really question it. You know, you're told this is the process, this is what you do and you just follow it right. You know one of the things that, at a long time, for a long time, azure, I would argue, had the upper hand on the IAM front with AWS because of their just-in-time capability, the PIM capability that was kind of built into it.
Speaker 2:Yeah, absolutely yeah.
Speaker 1:Because it you know, you, you mentioned it, it's functionality that's in your solution, right, and you can use it to overlay with AWS, as we're talking about right now.
Speaker 1:That capability alone is extremely important, especially when you're dealing with environments that have sensitive data. You know you want someone else to approve what you're requesting and what you're doing. The reason why you want that is because it removes a good amount of the liability off of you. You know, because you can send them a message and say these are the exact commands I'm going to, I'm going to run, here's the approval request and they can approve or deny. And then, if something goes wrong, you know you can point the finger back at them and say like, hey, well, you approved it. You know, and I I can't even count the amount of times I've seen someone get fired because they ran the wrong command, and you know, multiple people thought it was the right command, but they ran the wrong one and, you know, as it shakes out, they end up losing their job because they did something that they weren't intending to do.
Speaker 2:Yeah, and there's so many of those commands that don't do what they say they do. You know what I mean. They say they do it, but you don't truly understand what. There's a I think one of my favorite ones in Azure is like I'll do it, I'll say it wrong. It's like start, get access or get access URL, something like that. But whatever, it's this crazy one right that makes, like the file system on the VM a public URL. I'm like you don't even name the permission, what it does, it's just this crazy permission name. No one knows what that does, yeah, but you do it and you expose some data outside of your network control.
Speaker 1:So yeah, and that that kind of circles back to why you need experienced people in the cloud going into these cloud roles, which is, you know, it's backwards from almost everything that I talk about on the podcast Right, because you can't get the experience unless you get the experience right, like it doesn't go both ways.
Speaker 1:But in this instance this is a situation where you know you need to really understand and the best way to do that is through these certifications in the cloud. There's a reason why these certifications are so technical. You know they don't sound technical and they may even be just simple, multiple choice questions and I say simple with the caveat of that's a two paragraph question and now you have to answer 10 questions about it and they consistently get more difficult the farther down you go and by the time you get to 10, you think you answered one wrong, right, it's like, oh, I have to go and look at one through this other lens. I did that wrong, but the statistics show me if I change my answer, I'm going to get it wrong, right, like it's this whole mind game thing that goes on with these tests. Because you know, I was under the impression. If it's a multiple choice test, I'm sitting pretty good, I'm probably going to pass no matter what, and then you get into this exam and it doesn't feel like multiple choice, that's for sure, yeah.
Speaker 2:Yeah, the the variations in the traps that are in those questions are so in some ways, they themselves are an interesting pattern when you look at how they've actually built the questions and the multiple choice. It is definitely not multiple choice. You can't get your way through this one. It's not happening.
Speaker 1:So yeah, yeah there, you said it right. There's so many different traps in it. You know that are there just to make you think a wrong way.
Speaker 2:Right, and you have, and you have to say I understand this enough to not pick that intentionally wrong answer that is intentionally looking correct, correct, yeah, I forget the, uh, the, I forget which one of the aws certs it is that has the has a fair amount of the cost stuff in it. I always did so bad on the cost stuff because they'd be like which tier of the s3 should you use for this use case where you have this much in and out? I'd be like I don't know that one looks like the right one and you know I picked the wrong one and I was like darn it because I didn't know that if you used and I even forget them today, like which one was for which pattern on the cost stuff, but they're incredibly hard and the IAM ones are insane, you know again, should you use a condition statement or should you use the resource what is not resource to like it's? They're all crazy.
Speaker 1:You know, and when you're taking the exam they tell you up front, you know, something like 20 or 30 percent is I am. Yeah, you take the exam and it feels like it's probably 80 or 90 percent. Yeah, you know that. That just goes to show you how difficult and how important I am. Is you know at least AWS, right? I haven't taken any Azure certs or anything like that. I haven't really worked with Azure a whole lot. I've done enough so that I understand the terms that I would use. So I don't sound, you know, stupid to someone that knows Azure, right. Same thing with GCP. But it's like a totally different world, it's a different way of thinking. And that's why I like the simplicity of the permissions firewall because, like I said before, when I, when I approach it from the aspect of I don't know anything, let's see what we can, you know, kind of kind of pull away from the solution so that I can start understanding things, and the simplicity is is truly key.
Speaker 2:I again, and this is one of those things that felt weird as we were building it right and I hate to use this word, centralized, but it puts a bit of centralized guardrails back into I'm going to call it cloud ops or cloud infrastructure the people that run the large cloud infrastructure for the company, right, and companies like yours you have people that do that right but it allows the independent developer building their app to have slightly more freedom. In that we don't feel so bad if they put Lambda star, ec2 star hopefully not IM star and something. But you know, if they use these more wide, open policies for testing and things are working and they don't bump into the firewall, then they just continue about their day and the risk is actually fairly low in all cases. But the first time that they use a really sensitive permission right, they're actually going to change the security groups, they're going to change a route table, they're going to actually make a pre-signed URL or something. They bump into this like wall where at minimum somebody's got to press the approve button one time, right, and so it just creates this. It's very small friction, it doesn't cause very much, but it's enough that when somebody goes to use something that's sensitive. There's just that second set of eyes on it or that second thought to say, huh, that's interesting. Should the wide open permission on the VM actually have enough permission to do that? I don't know. Maybe we should create a different separation of duties there.
Speaker 2:And this is the neat stat. So if you go read that data kind of article we did, or survey like 92% of everything that has these very sensitive permissions right, and I think we in AWS it's around between 800 and 1,000 in that range of these very sensitive permissions Like 92% of them never use them. They have them but they never use them. And it really tells you that most of these developers that open these policies up a little bit too wide will never bump into that wall anyway. Right, because they weren't going to use them in the first place, but they didn't know how to configure it another way, because they didn't do the cert and they didn't spend the time. But it gives the cloud infrastructure team or the cloud ops team just that little safety net of guardrails there, applied at scale. Not that we wow man, we did a really good job. We finally got our most important workload to something that looks like least privilege. They can do this across, you know, hundreds of AWS accounts in one swoop, which is, I think that's hugely valuable actually.
Speaker 1:Yeah, it is extremely valuable. You know, we've we've consistently kind of talked down the singular AWS billing account, right. I've, I've personally seen an organization with thousands of those AWS billing accounts. You know, obviously it's an international, worldwide company, very large. You know, anyone would know the name, right, and it's insanely complex. You know to to, to put it, to put it lightly, it's insanely complex, right, and trying to ensure that all this new AWS account that we're spinning up doesn't have access back to the mothership but the mothership has access and visibility and everything that that account is doing and trying to create, like these many AWS clouds for different branches of the company. I mean, you know the the the company has such a large AWS presence that you know the cloud security side and the cloud infrastructure team is blended with the very exact same AWS teams. They sit across the aisle from each other.
Speaker 1:That's how large that environment is and the complexity with it is insane. It takes them four days to do anything. I mean, I've seen people put in requests to them, I've heard about it and it takes them four days to get to it. You know it's. It's just insane.
Speaker 2:Yeah, no, and there's again, as you say, everyone has built their AWS environment a little different too, so it's not like there are these massive cookie cutter patterns. This is one of the way that these guys did is exactly how all of these other companies that you don't. You have so many customers that are like well, we birthed the first version of AWS and kind of messed that up. So then we built the second version of AWS and we messed it up last, but it's still a problem. So then we built the third version, but the problem is you go and talk to them in year five. The version one is still running with some production workload in it, so that again, there's infinite flexibility.
Speaker 1:With that comes that complexity and as it gets bigger and bigger and you're trying to get those centralized controls, as you say, like the change requests can be massive in time and effort to even do the risk analysis of what that does. Yeah, and it's. You know, in terms of like technical work, it's very low. You know it's very low on the technical side. Anyone in the cloud would be able to do this thing. But when you hit that you know insane number of thousands of AWS accounts, right Like.
Speaker 1:You have to look at it through a different lens. You have to really understand it and know it inside and out and really, without having a powerful solution behind it, it takes four days. Literally, it takes four days and that's them moving quick, that's people harassing them and trying to get them to move it along and whatnot. That's four days. It's wild how complex AWS can get and or just the cloud overall, but with AWS specifically. It's also interesting to me as to why they haven't come up with something like this or come up with a more useful IAM solution and I like AWS. I'm not trying to, you know, talk bad about them or anything like that, but when I look at IAM as a whole it's like man, this has been a mess since I got into the cloud. Like how do they not think to do anything better?
Speaker 2:Again, I have my own theories and part of them are not that they didn't do it is that they their actual customer. When you really think about AWS, is the practitioner right, it's the developer, it's the builder, it's the. That's who they sell to, that's who they want to use their services and do that. And so when you think about what comes into their product management teams from their what they consider to be their primary customer, those people are builders. They build their own stuff. So when they give them back APIs and tooling like you know SCPs and you know we'll even look at IAM access analyzer, which the UI for it is horrendous but you can call APIs and get stuff out of it very easily. I think you know that's often what their developers ask for. But when you roll that up to and we see so many of these right you look at these kind of older companies that have embraced AWS and then built these enterprise solutions on it. There's somebody in that company that was a network firewall admin that's now in charge of AWS organizations in that place and he they're not his primary customer, but he's being asked to use SCPs and write rules that look, admittedly, like some pretty old firewall rules actually, but he has to understand the whole part of AWS to do that and the gut reaction for that individual would be okay. I have the tools to do it. Aws has given me the tools, but now I need a team to build this and whichever.
Speaker 2:And so, again, the cloud permissions firewall is interesting and people initially hear it and they sometimes think, oh well, you're in line or you've graded some jump box and you're actually monitoring. We didn't. Every single thing that does is AWS native, right, it puts in SCPs, it uses AVAC, it uses CloudTrail to figure out history, it uses the sensitive permissions. We have stuff where we call their APIs to find the permissions and rate them and all this stuff. But there's nothing that goes into that that is not AWS native. And so, really, the cloud permissions firewall is an AWS solution. It uses all AWS stuff. It's just a layer on top of it to make it so that you can implement it at scale. You don't have to decide what sensitive permissions are. We keep up with that. We give you an easy way to get out of jail when you've been locked out of a sensitive permission. But it's still using the AWS tooling for doing it.
Speaker 2:So you know, I think if you asked AWS, they'd say, oh, we did do it, we gave you all the tools. But you may have to have a team of I don't know. Our development team is pretty big right To go and actually build the overall solution. You still need a lot of developers to do it, and so I think you know will they build something exactly like this? I've looked at enough AWS consoles to realize probably not. Their tools don't work that way in their consoles, right, but they will continue to add functionality to it.
Speaker 2:We know there's something in preview that will be announced at Reinforce that adds to this SCP world, which is pretty impressive actually, and it does some. Really. It fills some holes that they have been unable to fill before. So I think they'll continue to add those and it will help. Solutions like Sunree help customers implement stuff without them having to go learn what those new things are on that side. So, anyway, I again like you, I like AWS a lot. We use it here, super happy with it, but it is complex and lots to learn as you, as you implement it.
Speaker 1:Yeah, it's interesting that you bring that up, that that you know. It's interesting the part that you mentioned where they were building out the different roles and permissions and whatnot, and it shows that mentality, it shows that you really have to know what you're doing right, because you can't come at it from a legacy enterprise solution Can't. No.
Speaker 2:Again. I've used this example before. I may have even told you. So one of the things in the cloud permission firewall which is kind of cool, we call them zombies, so these old identities that are not used anymore and we use ABAC to control them so we can basically short circuit them so that they don't work, but they still exist in the cloud and they can wake up with the permissions on demand. If somebody tries to use one of them it'll wake up saying do you want to do this? Yes, I do. But you.
Speaker 2:You ask like, why did we build that solution? You know a human could do that easily. You can just go into the console and delete them. There's all these things. You have Kim solutions, like the other Sunree solution, the CIM solution, like why won't you delete this identity?
Speaker 2:And the stories that we get are so interesting and this is one truly from my past where I screwed up in a scenario where we put rules in place. We said if the identity is older than X period of time, just delete it. And the identity was used for a configuring a system that had another function, but it was pretty old and didn't get changed very often. So the identity sat dormant most of the time. But the problem was when that was removed. You know that identity was tied to resource policies, it had an access key, it had all these things and when it got removed that was gone, but the team that built it wasn't there anymore and so trying to figure out how to put that back was insanely hard. And unfortunately, if you've been in AWS for five years, everyone has had a situation like that and you just get scared. You're like I don't want to delete that, I don't know how to put it back, and we came up with this concept of zombies and quarantine. And then this wake up because we needed a way to basically soft delete things.
Speaker 2:If you're familiar with Azure, in the directory you can set one of the identities to being disabled, but it still exists. It's a horrendous mess. You have all these RBAC assignments all over the place that have these identities that don't exist in them and whatever that are turned off. But AWS didn't really have that function and this was a way of implementing something very similar where you could basically leave it alone, leave all the resource policies, so they theoretically worked and stuff, but the identity was just short-circuited. It just would not run.
Speaker 2:When we were thinking about the solution, that wasn't going to be the most amazing thing we did. We thought it was all about these sensitive permissions, but when customers see it, they're like, seriously, we could do this to 10 000 identities? Yes, you could, and if it happened to be a break glass and it happened to get used in the middle of the night, somebody would just have to press one button to turn it on, that's it. And they're like that's amazing. And so sometimes you're surprised like what people you know. Again back to, sometimes the simple things are the things people really need. They just need them at scale.
Speaker 1:So yeah, that's a really good point. Well, sandy, you know I think we're we're at the top of our time here, but before I let you go, you know how about you tell my audience where they could find you if they wanted to reach out and where they could find Sonarish Security. You know, if they didn't want to look at the links in the description of this episode.
Speaker 2:I highly encourage the links in the description, but somebody is watching this in their cars or listening to this in their car as they drive down the road and can't see the links Right. So you know the best thing is just go to. You know, sonarishsecuritycom there's a learn section of that that has that data report that we talked to. It's a great spot there. If, for some reason, you're interested in the cloud permissions firewall, you can do a trial of it for 14 days. What's great is it goes in and monitor mode and doesn't change anything. You can just take a look at things and you can try all of the real active controls out as part of that 14 days. That's worth doing. And if, for some reason, you want to reach out to me on LinkedIn or something, feel free. I always love to talk to you.
Speaker 1:Awesome. Well, thanks, sandy, and thanks everyone for listening to this episode. I hope you enjoyed it.
