access2024

What is a Cloud Permissions Firewall Anyway?

Get the Free Ultimate Guide to SCPs

In this session

Speaker

Jeff Moncrief

Jeff Moncrief

Field CTO Sonrai Security

sUMMARY

Discover the Cloud Permissions Firewall concept and its role in modern cloud identity security. This session explores achieving least privilege at scale with a default-deny model that works, delving into real-world applications and benefits. See it in action to gain an understanding of how implementing a permissions firewall will solve the overpermissioned and unused identity problem in your cloud.

Resources

Read Summary
Imagine accelerating your identity security maturity in the vast expanse of the cloud. At the Access 2023 Cloud Identity Access and Permission Summit, Chad Lorenc, a seasoned security manager from AWS, shared invaluable insights on mastering this vital aspect of cybersecurity. Key Principles: Chad emphasized that all cloud access is privileged access. He stressed the need for understanding roles and centralizing them through robust organizational structures. By mapping roles to identity policies, businesses can tailor security measures to their unique needs. Understanding Cloud Identities: In the complex cloud landscape, comprehending the nuances of identities is paramount. Chad highlighted various identity types, from cloud users to root users. This knowledge forms the bedrock of secure cloud environments. Phases of Identity Security Maturity: Chad outlined a roadmap for your journey. Begin by establishing a baseline of identities. Then, build protections around your business objectives and fine-tune them for maximum efficiency. The ultimate phase involves continuous monitoring, ensuring your security evolves with your needs. Aligning Security with Business: Don’t just implement security measures; integrate them with your business objectives. Chad urged against merely promoting "least privilege". Instead, showcase how it streamlines operations, ensures compliance, reduces errors, fortifies security, and facilitates scalability. Key Takeaways:
  • Understand Identities: Recognize the diverse identity types in the cloud—from users to cloud owners.
  • Align Security: Integrate security seamlessly with your business objectives for tangible benefits.
  • Continuous Monitoring: Implement robust monitoring and response strategies, ensuring your identity security stays ahead of the curve.
Embark on this transformative journey armed with knowledge, and watch as your cloud security reaches new heights.
View Transcript
Jeff Moncrief (00:00): Awesome. Thanks for the introduction, Karen. I am super excited about this session. As Karen teed up, we are going to be talking about some practical applications of a lot of the things that we've heard about this morning in some of the prior sessions. Let me get into slideshow mode here. We will be going through a few slides, but we're going to be spending the majority of our time today in live demo, which is always very, very exciting putting some of these concepts to use. (00:33): I do run the SE team here at Sonrai Security. I'm also the company's field CTO, and I've been here now over four years and it is very, very humbling to look back and think about how much I thought I knew about securing the public cloud before I came over here to Sonrai and then fast-forward to today as I've learned so much about how identity should be the absolute core of any security strategy in a cloud-native landscape. (01:04): We're going to talk today about just some of the lessons that we've learned over here, some of the lessons that I've learned with customers that I've been working with over the years as it relates to putting these different practices to use, what's working, what doesn't work, some of the frustrations. We're going to spend, like I said, some time actually doing a live hack, exploiting a full identity attack chain and doing it live in real-time at the command line, and then showing you with the Sonrai Cloud Permissions Firewall, how it could have been prevented, and also how it can actually be used in action should someone try and do this to you, and then we'll leave some time at the end for Q&A. (01:44): We have been talking a lot today about SCPs and writing that JSON code and really building out a solid IAM strategy to secure AWS, but a lot of these concepts can also easily be extended out into Azure and GCP. Ultimately, what we've learned over the years here is that the market exploded about five or six years ago with Cloud Security Posture Management, or CSPM. Then came the evolution of CNAP solutions and then where Sonrai's been playing in the last four or five years, which is CIEM, or we call it CIEM around here, but it's really focused around entitlements and identity risk and visibility into the access fabric itself. (02:32): What we've seen over the years is that there's plenty of tools out there that show you that you have a lot of problems, that show you that you have lots of own permissions, person and non-person identities that show you that you have a lot of unused things that are out there. Certainly, I think that eye candy of those attack paths where you chain all of this together, like Chad was talking about in the last session with the role-chaining, but everyone asks us at the end of the day, how do I fix this mess? Traditionally, we'll call it in order to try and fix what we call the unused permissions attack surface, you've got to do it by hand. (03:08): Yes, if you want to secure the hub itself, the hub being the control plane in AWS, you've got to write SCPs by hand. They are powerful, as you have heard, and I've heard from prior folks that I've spoken with. You can also get in a lot of trouble with them if you don't know what you're doing, and they are very, very manual in that they're static and you constantly have to revise them by hand. That's doing things like trying to turn regions on and off, or services on and off, or really trying to restrict and lock down allows and denies into different services and parts of the public cloud environment. (03:46): Then you've got things like IM policies by hand here. This is your tool, whatever it is telling you you've got 10,000 different identities that have way too many permissions because the developers didn't have time to figure out which permissions they did or didn't need, so they just gave them star access to these different services or maybe the needs of the business have changed and those permissions have changed. Ultimately, you have all these different identities that you need to go get to least privilege, here's 10,000 recommended least privilege policies, good luck. That becomes a daunting, then an insurmountable task, and then folks just walk away because it's unattainable and certainly at scale across the entire public cloud. (04:31): And then you've got the other one here, which is probably my favorite problem to talk about, even though it's sadly the most risky problem that I see in the public cloud environments that we work with. That's all that cyber litter and cyber garbage. Folks make fun of me all the time, poke calling at me for calling it that, but that's what it is. All those orphaned artifacts that are out there, person and non-person, most importantly non-person. All those roles that were created to go do something at some point in time, and maybe they're needed, maybe they're not, but you don't know, and then you have to deal with the daunting task of figuring out whether or not you can safely remove those. That is scary and that is paralyzing. There's so much research that goes into that. Just whether or not you can delete safely, one of those identities can take weeks to figure out. (05:25): Ultimately, when you put the pieces of the puzzle together, you've got workloads that you're trying to secure that have instance profiles attached to them, they have the ability from a trust policy to go assume another role. Those roles, many times, 90% of the time, we've learned over the years, are unused. Those roles, guess what? Because of a cross-account trust relationship, it's another concept that Chad was just talking about. They can jump from one boundary into another and then that new identity that they have now become gives them brand new privileges and brand new entitlements, so they now can privilege escalate, they can move around to other identities if they want, or they can just try right then and there to see what they can grab from a data perspective. (06:13): That's really what you have to worry about. That's how the adversaries are thinking, that's how they're putting these pieces of the puzzle together to think about how they can use these misconfigurations and these unused components that are littered throughout the public cloud to their advantage to get to whatever objective they're trying to get to. That's what we're going to really talk about today is how you can actually prevent this. (06:36): First, we're going to show you what it looks like when it plays out and someone has a bad day, but then we're going to show you what it looks like when they have a good day. Really, the key is being able to orchestrate and manipulate SCPs and other parts of the orchestration mechanism that AWS provides you in order to really, really lock things down, but also to do it in a way that's safe and that's flexible, and that doesn't really hurt the business, it actually enables the business, and it can be done very, very quickly. We're going to talk about that a little bit now. We're going to show it to you live, all right? (07:17): I always like to prove that when I do these live hack things that they're fun to do, but I like to prove that they're real. I'm going to be on an actual EC2 instance. This is my sales engineering environment that we have here at Sonrai. I'm on this EC2 instance right here, I'm going to show you an SSH into it in a second, and you're also going to see here little thing that folks don't realize is that in order for this EC2 instance to do anything across the actual cloud platform itself, there has to be a connection to the actual identity fabric.That's this instance profile we call it here, and this role is attached to this EC2 instance. (07:59): This is where things get you in trouble is because a lot of folks don't realize that... They think that these are just standalone, siloed, isolated instances that are just out there, almost like a traditional BM or a bare metal server, but they're not. They actually have direct connections into the platform itself, into the identity fabric, and that is why we must think of the identity fabric not as a perimeter. I love what Chad said about the edge. (08:24): We must think about it as a network. The identity fabric in the public cloud is everything. There is not a single public cloud or cloud native workload that can function without the identity fabric underneath it. It allows everything to communicate, live and breathe just like a traditional network would through the access fabric, so we have to think of it the same way, and we have to come in and secure it kind of the same way. (08:52): This is the workload that we're going to be on. This right here is a screenshot from our core CIEM product. I'm not talking about that today, I'm not going to show it to you, but I want to show this to you because this is actually what we're going to be doing. This is that instance, this is that workload. Here's that instance profile role that I showed you that's attached to it. Now, what you can't see unless you really know what you're doing here, or if you're an adversary and you have a lot and you have intent, is that this has the ability to assume another role in that same environment. That, because of a cross-account trust relationship, allows you to break that boundary and jump into prod as another identity called medical results reader. That has data read permissions on it with this particular policy. (09:37): I like to show folks this because this is exactly what I'm about to exploit in real time for you at the command line. All right, having said that, this is my command line. I'm going to minimize the Chrome browser here so there's no distraction in the background. Karen or Matt, if for some reason this isn't big enough, I need to enlarge it, please let me know but I do have it pretty big now. Just to show you that this is real, I'm actually logged into the EC2 instance now. I'm going to log out of it. I'm actually on my MacBook right now. I'm going to show you that I'm just going to SSH right back into this instance. (10:12): Now, as the story goes, I could have exploited a zero-day vulnerability, I could have grabbed this credential, this PIM file off of a GitHub repo that may have accidentally been exposed the dark web. There's 100 different ways that I could have gotten access to this workload. That's not the point of today's conversation. The point of today's conversation is when you're on a workload, what can a bad day look like? I have written a script that actually automates a lot of the manual commands that I would otherwise be issuing to exploit the kill chain that I just showed you. I've got it right here in I'll show you. I am in the EC2 user home directory and I'm going to list the contents. (10:58): You'll see there's a couple directories, a couple of files, but there's something here called iamwalker.py. If I just VI that file, you're going to see that I have written a script, it's about 500 lines long, and what it does... I call it the iamwalker, it is going to actually go through and traverse the identity fabric from wherever you're currently accessing that public cloud environment from. I could have easily exploited this workload, dumped this into this Python file, just copy paste, off to the races. You'll see what it does is it retrieves who you're currently logged in as, it displays that caller identity, it is going to then start to enumerate all the roles and determine whether or not they can be assumed. (11:41): That goes on and on, and I'm happy to go through this with anyone that's interested in a later point in time, but it essentially crawls through, attempts lateral movement as far as it can get,, it's menu-driven and it tries to get data. This is exactly what we're going to use. I'm going to get out of here and we're going to now just launch it. Yes, I did a cute little banner there just because I could. You can see the menu here. If I want to confirm my current identity, remember that attack path that I showed you here. There you go. (12:17): It is the current role of Tableau Tester, it's attached to that EC2 instance if you recall me showing you that in AWS. It says that I'm in this account, which is a sandbox. As an adversary if I just pop the workload, interesting, great, now I know who I am and where I am. If I want to try and see from right here, directly attached to this instance profile, if I can enumerate data containers, there you go. This says that I can list S3 buckets, but I can't list DynamoDB. (12:48): I could go after any other data structure or unstructured services in AWS, but I'm trying to keep this simple. I see there's a couple of S3 buckets that I'm able to see. The question is, can I enumerate the contents of them? I'm going to choose two, which is Sally's secret stuff, and see if I can see what's in it. I cannot. Access denied, no permissions. I'm going to hit B, the menu, just takes me back. Again, confirmed by current identity, I'm still Tableau Tester. (13:16): Now I want to enumerate roles, which is option two here. It is going to go through and enumerate every single possible role that that existing role the Tableau tester has access to. Because I am a poor coder, I've got a loop in here for some reason, I've got to go fix. I haven't had time, that's why you see this here twice, but it went through and it found that there's 89 roles that I could potentially assume. There's 12 assumable, 77 unassumable. What it does is it lists the 12, 1 through 12 here that are assumable. Now, in the essence of time, I'm going to choose 11. 11 is deploy infrastructure. That is the next step in that attack chain that we showed you. (14:04): Now you can see that you are now Deploy Infrastructure and that you are still in that sandbox account. Now, this is cool. I built a capability here on the menu that shows the lateral movement path, and it just is keeping track of where you are and the identities that you traversed. It shows that we came in from the internet, we are in a sandbox environment, we hit the EC2 instance. We were automatically Tableau Tester, now we've become Deploy Infrastructure. Same thing, I want to see as this current role, can I enumerate data containers? I cannot. Access denied, access denied. That's crummy, but I'm a new identity so what can I do? I can re-enumerate roles and see if I can hop somewhere else. (14:48): This is exactly what Chad was just talking to you about with role-chaining. How quickly I went from one identity to a second identity now can I become a third identity. It's going to do the same thing. It's going to enumerate, see what I can assume, give me options here of what is assumable and you'll see that there's a new identity here called Medical Results Reader, number 13. If you recall in that tag path, that's the last hop cross account trust exploitation. I'm going to become that. It says I'm now in prod as Medical Results Reader, and if I show the updated lateral movement path, here you go. It shows that I've crossed the boundary, I am now gone from sandbox to production, and I'm now Medical Results Reader. (15:38): This is exploiting roles that are unused. It's exploiting trust relationships, and you're about to see it's going to give me privileged escalation. Now as this current identity, if I try and list the available data containers, here you go. Now I see S3 buckets, now I see DynamoDB tables from production. Let's just say I wanted to see there's this medical results DynamoDB table, what does it look like? The script I've got actually just lists what's there, and you can choose what you want to take a look at. (16:12): I'm going to take a look at number nine, medical results. There you go. Here's the contents of the DynamoDB table, and we've got fake data. Maybe it's a blood type, positive, and the name, email, it can be whatever. You can tell this is just hacked together because they're not even spelled right. It's just for demonstration purposes but this could very well be something that is very, very sensitive to the business. (16:40): I'm going to try and do something for S3. I'm going to choose option number eight, which is X-ray image data. That looks juicy. What does it do? It enumerates the contents of that, and you see some PNG images. From here, I'm going to choose option seven, which is 9.56. Remember that. It's actually going to grab that file, put it on the local directory, and then watch this. I'm going to get out of option B, 6, exit. If I go into the stolen data directory, there's the 9.56. If I actually do it like this, [inaudible 00:17:27], you'll see the size of that image there. It's about 16 megs. It's one meg. I can count 1.6 megs. (17:34): That quickly, I was able to jump from one, two, three identities, enumerate data, two different types, and quickly siphon off this file right here that I can then just extract however I want. I'm already SSH in, I can just SCP it out if I want to. Very, very simple to exfil. If this isn't a bad day, I don't know what is. This is what we do. With the Sonrai Cloud Permissions Firewall, this is it right here, again, I'm not doing a big product pitch here. This is very, very practical. (18:13): Now, the cloud Permissions Firewall, just so you have somewhat of some context, is the way that Sonrai has really, really innovated, and we have worked our tails off for the last year to come up with a way to answer that question that I set things up with in the beginning. How do we fix this mess? How do we fix those identities across that lateral chain? How do we get these thousands of things to least privilege? It's unattainable with just a limited staff. This is what this firewall is designed to do. It is all about action, and it plugs in the simple role, it quickly discovers everything that's out there in your running cloud and the most important component that it discovers is the vast part of your currently turned on enabled cloud that's not used. (19:03): We call this the unused permissions attack surface. You'll see here that we have these roll-ups but ultimately, there's 330 something services that are out in AWS. Here at Sonrai, we only use around 21 ourselves, but all of those 330 services are turned on and enabled by default. They are a risk to the business that does not need to be there. How would you go fix it today? Running SCPs by hand. It is a pain point that we hear about day in and day out from folks, and that's why we created this. (19:36): If you think about things like EC2 that everyone's heard of, everyone uses, it's a core service in AWS and if you look at some of these different accounts that we're monitoring here in this demo environment, we've got an automation account that's got 43 identities that have access to what we call sensitive permissions. Not all permissions are created equal. What we've learned over the years is that folks are really, really concerned about the permissions that can hurt their cloud, give them a bad day. What does that mean? It means things like creating VPCs, associating route tables, attaching internet gateways, cloud trail, turning off cloud trail, those kinds of things. (20:18): We heard Nigel in the prior session talk about SageMaker and the risk there with creating pre-signed URLs. It's real and things can be used dangerously against the company, either intentionally or unintentionally that aren't needed, and the vast majority of things that are out there that have these permissions don't need them. With the firewall, we just click this protect button, and what's it going to do? It's going to lock down this environment and say that these identities, they can't access those dangerous permissions, but they can use the other permissions, the lists, and the describes and those kinds of things, but it allows you to quickly get environments to least privilege. (20:54): Right here, zombies, this is my absolute favorite part of the firewall. This is attacking what I just showed you. I have all these unused artifacts that are out there that are creating all this risk, creating these lateral movement attack paths. How do I fix it? I can't realistically go do research on 2000 identities, and 2000's low. This demo system's only got 169. We have seen tens of thousands of zombies when we plug in. These are things that are out there that you just don't know whether or not you can safely remove them. You can see through these different environments that we're highlighting with the firewall things that haven't been used in 5 months, 9 months, 10 months, et cetera. (21:37): We've actually come up with a better way and said, we don't have to delete them. You don't have to do all that research. You just hit this quarantine button right here and it's just going to throw them in identity jail. They won't have the ability to use their entitlements, but we're not deleting anything. We're simply putting a layer of isolation around it that says that it cannot function live and breathe without the firewall saying that it can do so. That's the same workflow for over here when we get these different identities and services protected with the firewall. (22:07): Someone needs something, same thing with the zombies. If it wakes up, we've got this really cool capability called permissions on demand, where we're going to be able to grant that entitlement back to them either temporarily or perpetually using Slack or Teams. It's super slick. I'm going to show it to you here in a minute in a real example of a good day, and then we've got services and regions over here. I mentioned that we don't use the vast majority of those services. Most organizations don't. Like I said, they're turned on by default. (22:36): This is where you can really get in trouble with folks poking around doing things that are not supposed to be doing possibly with new things like AI. W talked about Bedrock, those kinds of things earlier. How do you control this today? By hand with service control policies. Right here, you just disable them at any particular scope across the org or in any of these different child OUs and child accounts. Super easy, and the same thing with regions. Regions, so many are turned on enabled by default. 17, actually, it's a little known fact, something I learned just recently. You don't need them all. (23:10): You think about shadow IT, cross geo data transfers, and the trouble that you get in there with compliance violations, just turn them off. How would you do this today? By hand. If you think about these two over here, these are really focused on controlling the control plane itself. You think about these two over here, those are focused on those spokes themselves. But when you click these few buttons, it is absolutely beautiful to see what happens to those lateral movement attack paths. They absolutely collapse. (23:40): Whether it's your CNAP or your CSPM or your CIEM tool, those dials go straight from the red towards the yellow and the green because this is actually taking big chunks of risk out of the identity fabric quickly and safely. It's really, really meant to attack the pain point of writing SCPs and least privilege policies by hand, and we're really locking down a vast part of the public cloud that is out there, but unused. Some of our studies that we've done with customers, greater than 90%, 90% of what's out there and enabled able to be used, able to be exploited. What I just showed you is unused. (24:24): Think about that. Really cool capability, but I'm going to show you something here. We have actually protected my sandbox environment. I click the magic button here, protect your cloud. That goes through, and it just does this with one click for you. But you'll see here we've actually got a new zombie that's popped up in the last 92 days. I actually clicked that magic button around 120 days ago. (24:50): In this environment, I'm going to go to the quarantine list and we're going to show you that in this sandbox environment, we have put in identity jail, 58 different identities. You can see person and non-person identities. Again, these machine ones looking little robot icon, that shows you the machine or non-person identities, and you can see how quickly they start to outnumber the person identities. But you'll see as I scroll down here, we've got a zombie that's been quarantined called Woodbury. You're going to see things in here like Rick Grimes, the Quarry, et cetera, because well, Walking Dead. We had a little fun with our naming inventions, but it fits well with the whole zombie theme. (25:34): What I'm going to try and do and show you what this looks like when I try and wake one up. To bring it back to the example that I just showed you, as I told you before, that identity chain was unused, that I just exploited by hand. Had I used this, I would've clicked that quarantine button, it would've isolated every single one of those, and just think about it like a red X on every one. You're not going anywhere, you cannot live or breathe unless the firewall says you can. That's what I've done here. This one, we've taken care of the risk ahead of time and it can't be used against us. (26:07): What I'm going to do is I'm going to come back into my script and we're just going to now try and become that Woodbury person. I could do this with the STS assume role command if I wanted to, but that's just, I've got a tool for this, so I'm going to open up the walker. I'm in the wrong directory. Let's try it again. There you go. Now I'm in the walker, I'm going to enumerate roles, see what I can assume. You'll see Woodbury there as option 10. I'm going to become Woodbury. I'm now Woodbury. Okay, let's verify. Am I Woodbury? Woodbury. (26:51): All right, now let's try and do something. I'm going to try and list available data containers. Instantly, access denied, access denied. Now, what if this is some critical identity that you are fine removing the risk up until that point, but you also have protected yourself from deleting something that could have been critical to the business. Maybe it just does once a year year-end reports, once a quarter, whatever that might be. With the current methodology of writing SCPs and least privilege policies, you will have broken that and good luck trying to fix that quickly because it's going to take days of research and tickets and all kinds of conversations with folks to figure out why it won't work. If you had deleted it, that's even worse. (27:30): What happened is in real time, right here, you'll see that 12:56, which is just a little bit of time ago, we got this come across through Slack, and it's where it actually says that the zombie, Woodbury, and that particular account attempted to perform AWS S3 sensitive permissions and actually use it, and enumerate sensitive permissions. This happened in a split second. All I have to do is add a note and say that's fine, and I can approve it, and that particular permission will be granted back to that zombie. That zombie can wake up and it can actually try and do something, whatever it was meant to do, or you can deny it. (28:16): You can deny it, which is even a cooler use case because it could be a potential indicator of compromise that the zombie should have never woken up. You were protected from that risk all up until this point in time, and the firewall actually prevented the identity from waking up and trying to use that entitlement that it did have. You have that net new capability, you can have that forensic investigation. We have that information here. You can know that it attempted to wake up and again, that could be a credential stolen, GitHub, something like that. Ultimately, the firewall was there to make that decision for you in real time and help you. Should it wake up or should it not wake up? (28:55): Just a really cool capability there, and that shows you what it could be like with life before something like this or life after. Again, you don't have to use the firewall. You're welcome to do this by hand. You're welcome to do this by hand. We talk to folks fairly often that are like, "I'm going to try this by hand," or whatever, and then we talk to the folks that have tried it by hand, and then we see what a massive pain point that we're hitting here for them by automating all this, and they never have to write another piece of IAM policy by hand, and it's flexible. (29:30): Just a cool capability there, and I hope that that scenario really helps you understand how these ideas, these models, these concepts, they matter. The vast majority of the environments that I've seen over the four plus years that I've been here. Now, when I say environments, I'm talking about the access fabric. Not the network, not VPCs, not NSGs, none of that. I'm talking about the actual access fabric itself. They're flat. (30:01): You have to think of it that way. It's like building a data center and just forgetting to put in firewalls. Everything is flat. You have to segment, you have to lock it down, and the way that you do it in the public cloud, the way that you do it in AWS is the way that we've been talking about it all day-to-day, is by writing SCPs, writing these privilege policies, and removing all that unused risk. Creating those boundaries.This just gives you a way to get there quickly, easily, and safely. (30:30): Go back into the preso here. Now, what is the takeaway there? How do you get to least privilege? You don't necessarily have to do it with something like the firewall. I do recommend you at least try it for the visibility, though. It's quite enlightening, but you restrict access to sensitive permissions. At least you've scoped it down from AWS having over 15,000 permissions to there's only around 900 that are dangerous. You need the ability to really understand which permissions could do harm to the business so that you can start to take action against things that could really, really put the business at risk instead of just a bunch of permissions that really don't matter as far as causing harm to the business. You need the ability to isolate unused identities. (31:18): Again, this really hits home at the fear and paralyzation that I've seen folks struggle with over the years when it comes to how in the world can I safely delete all of this stuff out there that I just don't know who created it, why they created it, and am I going to need it two days down the road or 250 days down the road? The two right components. This is just... I don't want to call it dirty little known secret, especially Chad and I are friends, Chad Lawrence and I are friends, so nothing negative on AWS. They want you to adopt services, they want you to use them, they want you to use those regions, and they offer incredible capabilities for businesses and allow them to solve incredible problems. (32:05): But from a risk standpoint, those aren't turned on by default. There's 17 regions turned on by default, but there's over 300 services that are turned on by default. Turn them off. Turn off the ones that you don't use. It's that simple. Do it by hand, do it with some tools like we've taken a look at in this session but ultimately, it is in incredible to see what happens to all those dashboards that are showing you identity risk with least privileged things, unused things, and then attack paths when you remove the unused part of the public cloud. Just some really good takeaways there. (32:45): Now, if you are interested in trialing the Cloud Provisions Firewall, as we've been talking about through this session, you have the ability to do a 14-day free trial. There's also a really cool offer that we're doing where you get five accounts of monitoring and protection for free for a year, which is really, really cool to try and get a hand on this risk landscape. With that being said, I'm going to turn it back over to Karen. Karen, do we have any questions that have come in? Let me disable my screen share? Karen Levy (33:21): We sure do. That was a lot of information. If you weren't able to follow the chat as you were busy presenting, people definitely were following along with you, understood what was happening, and quite lots of wows and excitement around the attack portion of that. Jeff Moncrief (33:36): Cool. Karen Levy (33:38): Lots of questions. Someone's asking about versioning of the SCPs. Do we have version control over them, and ultimately getting back to a rollback scenario. Are we keeping track so that you can roll back to a previous state? Do you want to talk about versioning? Really, I think the answer is more what we call rollback. Jeff Moncrief (33:58): Yeah, that's exactly what we call rollback. We do version everything, and what we do with the firewall is we actually do infrastructure's code through CloudFormation. That's one of the big reasons that we use CloudFormation is because it allows us to drift protection version control. If we need to roll back, it is so easy to do that, remove those changes very, very quickly. That's one of the reasons that we chose that as our primary mechanism, Karen, to deploy our controls was because of that ability to quickly just revert changes that may have been made and get things back to that prior state. Karen Levy (34:37): Jaydeep has a similar question. I think you just talked about CloudFormation, which is what we use. Jaydeep is asking do you generate Terraform or do you go and manage SCPs directly? The second part of this question is what permissions do I need to give Sonrai, which is a great question we hear all the time. Jeff Moncrief (34:58): We do not generate Terraform. We generate CloudFormation for a variety of reasons, but we know that the vast majority of the folks that we work with, they're deploying their infrastructure, their app teams, their DevOps teams are deploying that through Terraform. We know that. Actually, that's how we do things here internally at Sonrai is we use Terraform for the majority of our infrastructure's code and pipeline pushes. (35:20): Because of that, we generate a CloudFormation in a way that is designed to play very nicely with your Terraform. We will not interfere with it. They play very nicely together, you're welcome to continue using Terraform to deploy your workloads, and then you leverage us just to deploy up that CloudFormation to actually just really, really protect and lock down the running cloud. (35:44): Terraform is really your declarative state, how you want your cloud to be configured, and that's amazing. Think of the cloud Permissions Firewall as the way that we are going to mandate and dictate the way that your cloud will run from a running perspective and what's on the use and unused, but we will be pushing out via CloudFormation. (36:03): The other cool thing about that capability is that we don't require admin permissions into your cloud. Because of that, we're generating that CloudFormation for you right there on the firewall. You can download it and insert into your pipeline however you want. We actually have customers that are downloading that and then serving into their Terraform pipeline to push out. Or you can pivot straight from the firewall directly over into CloudFormation and deploy it yourself at the organization level. (36:29): At that point in time, you're using your rights, your permissions, and then just a few minutes it reconciles back with the firewall and then everything's in sync, and then you can take a look at our next recommendation of things that might be unused or things that you need to go lock down, then you can implement another [inaudible 00:36:46]. Karen Levy (36:46): Great. Jeff, you and I have... I've been here for about two years. You've been here much longer than me. I think we both fondly refer to the term acronym soup in the world of cloud security. Here's someone trying to unravel acronym soup. So question is where does the Sonrai Cloud Permissions firewall work with a CNAP, how does it deploy with a CNAP? Is it CIEM or [inaudible 00:37:14], and how does it compare to other commercial CNAP platforms like Prisma, Orca, and, Wiz? Jeff Moncrief (37:21): Yeah, as you started listening to them, I was like I'm sure I'm going to hear Wiz. As we all know, Wiz came around three years ago and just absolutely dominated the CNAP market that they led the way with. It's interesting because when we were at CIEM, a CIVN, we used to get compared so many times to CNAPs and to CSPMs. Now we're not compared to them at all. We just fundamentally do something very, very different that they do. (37:50): We have got customers that love their Wiz, that love their Prisma for visibility that might be using... A customer that we're working with that last week, they scanned our CloudFormation template with Wiz just as a mandatory vulnerability scan. We play right along well with those. They protect your workloads with their CWPP capabilities, their compliance reports. That's great and all. (38:14): At the end of the day, though, we've been there done that, and the customers that we work there, they've all been there, done that with that third party tooling or that native tooling that's just showing you a bunch of things that are misconfigured and wrong with your cloud across the platform, certainly focused on the identity fabric itself. That's really ...a CNAP or CIEM, they're going to be saying, go fix these 2,000 problems, including push out these least privilege policies, go delete these unused roles, and go fix these attack paths but at the end of the day, you're staring at the problem still. (38:49): That's fundamentally what... We created this to actually take action and to fix that risk and that mess for the first time. The firewall is designed to actually come in and expose and illuminate that attack surface in a way that is easily consumable and simple by the end user, but more importantly, to hit that button. Hit that button, all that risk just goes away and that's fundamentally something that we do that you cannot do with a CNAP or a CSPM. (39:18): They have their role for visibility and for reporting and for really focusing on infrastructure's code and vulnerabilities on workloads, but this is designed to actually make you the hero at the end of the day by quickly removing all this mess in a way that's safe with just a click. Karen Levy (39:39): Great. I'm going to combine two questions. Is quarantining of zombies done using an SCP, and if I already use SCPs, I find them really limiting. How are you going to coexist with my current SCPs? Jeff Moncrief (39:56): Yeah, so zombies, I'm not going to be able to give away our secret sauce. We'd love to talk to you about that at a deeper conversation under NDA, which it's totally easy to do and be a logical next step, but I will say that SCPs are involved in the way that we're doing quarantining. (40:15): It is a very, very clever orchestration mechanism that we have developed that we put out there using cloud native controls, Karen, with just a few clicks. We have multiple patents that are pending on this. I'm not going to be able to give away too much, but SCPs are part of the puzzle that allow us to do that and quarantine those with a single click. Very, very cool. I apologize, what was the second part of the question? Karen Levy (40:41): Are you going to coexist with my current? Jeff Moncrief (40:43): We will absolutely coexist with those current SCPs, but what we're already starting to see is folks switching over their whole SCP methodology to using the Cloud Permissions Firewall instead. It's because they're having to manage those by hand, or they're struggling with the size limitations of SCPs. We've developed the cloud permissions firewall in a way that we call SCP compression. Again, it's that clever orchestration that I talked about. There's three or four different mechanisms that are working together. Only one of them is an SCP but ultimately, yes, we will work just fine with the SCPs that are out. Karen Levy (41:20): All right. We've got about a minute for you to answer this one, so speed round. Back to all the different tools out there, how is this tool different from a JIT or other PAM tools that are out on the market [inaudible 00:41:31]? Jeff Moncrief (41:31): That's the other flip side. You got CNAP and CSVM, and you've got JIT and PAM on this side. We only have about a minute. I'll be real clear. JIT and PAM have their role. They're fine for user provisioning in real time on demand temporarily or perpetually and they do that, they grant someone a permission to do things quickly. (41:49): We are focused here with the cloud permissions firewall about coming in with a default deny on what's already out there. All those entitlements and permissions that are out there, the new ones that you're pushing out with your Terraform code, the vast majority of we're exposing and protecting here are machine identities, non-person identities, roles. It's a completely different language than what you're doing with JIT and PAM typically with user identities. (42:12): The other thing that we're doing here is really focusing on the control plane itself by locking down services, locking down regions. Those are things that are really, again, the core of the identity fabric that you must focus on as well, as well as those identities that you cannot manage or control with a JIT or PAM.

Up Next

Protect Your Cloud In One Click Without Disrupting DevOps

Start a free trial or get a live demo with our cloud experts to see the Sonrai Cloud Permission Firewall in action.