Jason Kao of Fog Security

Welcome back to another episode of Modern Cyber coming to you once again from the sidelines of Forward CloudSec. I always tell people this is actually one of the highlights of the year in the cloud security calendar because this is really a conference focused on practitioners and on deep research. So it's not a conference that's dominated by sponsored talks coming from, different vendors who have a very particular bias to view on things. Not to say that that's bad necessarily, but this is where you get to deal with, hear from people who have dealt with real world problems at scale. An example of that is somebody that we're going to talk to today, Jason Kao.

Jason, thank you so much for taking the time to join us here. I'd love for you to start off just with a little bit about your background, maybe, you know, where you're at right now, but also your journey into cloud security. Yeah. Thanks, Jeremy. Thanks for having me.

Happy to be here. So a little bit about myself. I started off at Cisco as an engineer, went to Fidelity Investments, got into security, started building cloud security, ran a team there to build cloud security on Fidelity's initial migration to cloud, and that's how I got into cloud security. From there, I jumped to Pretoria and did offensive cloud security consulting across anywhere from Fortune one hundred's down or down or up depending on if you see it to start ups. Yep.

Then went to CloudQuery to run security research as well as, some of their, solutions engineering. And then recently, I've started my own thing called PodSecurity working on specifically cloud data perimeters and preventing cloud ransomware. Yeah. Yeah. I wanna come back to that ransomware topic and update it, but, you know, that's quite a journey.

And, you know, just as I mentioned in the beginning, like, this is kind of the background of somebody who's been through the weeds. Right? Right. Right. Dealt with scale, who's dealt with complexity, who's dealt with very high value environment with a lot of very valuable data that attackers would love to get their hands on.

Right. And so I'm sure that journey has informed a lot of your thinking around where the real risks lie in terms of, like, how do we protect our data. And there's something that you said that I think is very important to understand, and that is this this what are we really trying to protect when we're protecting cloud environments? Like, for the most part, it's not the concept of protecting the environment itself. It's protecting the data inside the environment.

Right? Right. Right. And that's that's a really good point. Right?

Because one of the things I often think about, right, is, you know, the talk that we, you know, we're just talking about today or some of the topics are related to identity and access management. So in this case, we, you know, focused a lot and did a deep dive in AWS. One of the things that we see, right, is, okay, how do you explain risk to someone? Right? Because Yeah.

If I say, like, hey. I can create a new user who has administrator privileges within AWS where I can I, you know, took some access keys in there? They have administrator access policy, which sounds foreign to a lot of people. Right? What is a true impact?

Yeah. I think part of it, right, is if you look at, you know, your cloud environment, someone else's cloud environments, right, you may see an s three bucket with sensitive data with PII in it. Right? It should have, you know, if you're looking at, you know, hospital, you could have, you know, medical records, or you could have financial information. Right?

You could store this in different databases. Right? Yeah. And, ultimately, it's about protecting customers, protecting, you know, even internal records, right, and what is considered, things that are sensitive or even, you know, ancillary things that should be secured. Right?

So it could be infrastructure. It could be data and databases, data stores. Right? It can even be access to those or anything related to those. Right?

And Yeah. There are so so many different techs, so many great so much great research that comes out of this conference about how to secure those pieces. Yeah. And so to that point, when you think about this concept of a data perimeter Right. You know, I've had a lot of conversations with people in the past to try to explain cloud to them just who in general terms.

Right? And and, you know, you get a lot of the kind of misconceptions around, like, oh, it's just somebody else's computer and it and you also get the common misconceptions that it is by definition less secure and Right. People don't necessarily understand the shared responsibility model and everything that goes with it. Right. But in particular this concept of a perimeter I find is often one that's really like mind boggling for people who are coming from a more traditional network architecture background.

Right. Give people this one example use case of like, okay. In the days when I ran data centers for a couple software companies that I worked at at the time, let's imagine that I wanted to make one backup public to the Internet. Right. Right?

Like, that is really hard. Right. I've got my perimeter firewall, and then I've got my DMZ, and I've got my network address translation layer, and I've got my private IP addresses. And by the way, like, this backup thing is hanging off the back of the network. It's gonna be on a separate, LAN or a separate, bus.

Right. And and then, you know, within that backup, I've got, like, all these things that are private by default, and I wanna make one of those things public. Right. Like, that is a a complicated network path and and traversal that I would have to enable. But in the case of cloud, I can do it with, you know, like two configurations.

Right. Right. And so, like, where the perimeter lies, I think, is something that a lot of people don't understand necessarily as they make that transition to the cloud. Right. Even less so this data perimeter.

So when you think about that concept, how do you explain a data perimeter to somebody? Right. And I I think that's a great example of using, like, what it may have looked like from infrastructure perspective in the past. Right? Because one of the things I think about is, you know, it it it was it'd be like a scene straight from the movies.

Right? It's to break in or take some data. Right? So I don't have to break in your fortified data center. Right?

Get all the way through. They're, like, doing some dangling from the ceiling. Right? And they steal a hard drive. Right?

There's a lot of security around. Right? And to that point, right, you know, it used to be a very, like, castle analogy is often used. Right? And it's, like, everything within the castle is really hard to get to.

Yeah. And to your point, right, it's like you said, right, there's two configuration items and something could be public. So the way I look at it is I use a I use a different analogy here. So imagine, you know, you have a house or apartment. Right?

Okay. And, you know, let's say the front door is typically the way in. Right? And that's the outermost where you could even take a step further and save the offense. Right?

Or let's say the front door. Right? So the front door, if someone malicious actor is trying to get in, right, and they break through your front door, if you leave your crown jewels, right, your your jewelry, right, maybe a stash of cash, right, your most important assets or, like, sentimental items, like, right by the front door, The, you know, per military actor gets in and just takes it right away. Yeah. Right?

But and that's, let's say, the data from they're very outside of your, like, your your infrastructure. Right? But if, let's say, you have it within, like, you know, not just the front door, but it's in your bedroom, there's another lock behind this, like, secret closet. Right? Yeah.

And then you have a safe in there that requires a separate combination, then that's where you're typically gonna store your most important information. Right? So you might store or most important, like, sentimental, you know, things, items, whether it's, like, a ring that's been passed out for generations. Right? It might be a stack of money or, you know, something that means a lot of value holds a lot of value for you.

Okay. And that's one of the ways I look at data perimeters is, like, you see the perimeters like the outside of the house. Right? And then Okay. Like, the smaller perimeters inside, right, are, like, the safe.

Right? So, you know, if you have a roommate, for example, that, you know, you've you've met and, you know, you like them, you trust them, right, but not that much. Right? You're not gonna give them access to the safe, but they have an access, you know, access to your house. Right?

Yeah. So you can see that as, like, a different zone of trust. Right? Okay. So I see that as, like, zones of trust.

Right? You're not gonna get the public access to your house, but some people may have the code or your key to check on your animals or etcetera, but they may not have access into, let's say, the bedroom or, you know, your office or your eventually, like, the safe in your office. Right? And that's how I see it as, like, these centers or where these rings are zones of trust Okay. And how to protect, right, what's most sensitive.

Right? So, you know, your spam mail that you get in the mail, right, that you get, you know, from catalogs, etcetera, you may not put those in that safe. Right. Or you would probably leave them, you know, inside your house and not outside. Right?

Yeah. Okay. And so along those lines to kind of extend the analogy a little bit, if you think about this, I think one of the things that is, again, not necessarily immediately obvious to people is, like, you know, okay. I'm used to this castle and mode analogy coming from traditional data center and Right. Primarily, like, my mode consists of network access.

Exactly right. But when I think about a data perimeter, it's probably a combination of network access and identity based access Right. In the environment. Maybe coupled with something like, oh, I've got, you know, this AWS account which represents one house and another AWS account which represents another house. So I've got a combination of, like, account plus network plus identity that might govern or, like, actually determine whether I do or do not have access to some piece of data.

Right? Right. And that that's spot on. Right? I think one of the things that has been a shift is it's we're shifting away from these, you know, network perimeters, right, these network architectures.

Right? You mentioned a lot of them earlier into a more identity focused world, where to your point, it's identity. Right? There's some might be some networking. Right?

And there is also infrastructure like AWS accounts. Right? And that whole conceptual piece of what is an account. Right? What is what does I'm in AWS actually mean?

Right? You know, what has access. Right? Is it like a it's no longer a traditional database. Right?

It's you know, you may have something in I'm right. You may have an I'm role or principle. Right? Or you may have you know, the common example I'd give is, okay, these access keys were exposed. Right?

But who has access to them? How can they get in what access they have? Right? So it's this whole a little bit of a paradigm shift where identity is becoming, like, the new norm, and that is so much more focused on identity driving perimeters, right, and driving how to build successful security for protecting data. Yeah.

Yeah. Well, let's talk about that a little bit more because I know the topic of your of your talk here at Fort Worth Cloud Tech was around identity and access management and how, I love the title, something about how it's duplicitous. Correct. Yeah. And it's a little bit of a play on words.

Right? Because duplicitous has multiple different meanings. Yeah. But the the true reason, right, and it's a little bit tongue in cheek is that, there are I'm permissions, right, or different duplicate I'm permissions that can do the same thing. Right.

And the common examples I would give, right, is looking at, resources such in SQS, which is a little bit more technical, but a simple queue service. Yeah. And there's something in AWS called resource acts or resource based policies. And you can you know, with these different permissions, right, there's multiple ways to grant access for someone to use your queue or access your queue. Yeah.

Okay. And so, so it's duplicit as it's kind of building on, like, the fact that, like you said, there's multiple ways that you can govern this access. Right. But I imagine that also presents multiple ways for people to get confused about who has access to what. Right.

And that's that's one of the difficulties of identity access manager, right, is the nuance of understanding what permissions are there and who has access. Yep. And, you know, other some of the other examples we we covered in the talk. Right? It's like, okay.

Well, if I let's say I protect this one permission, right, in AWS that you can deny permission so someone doesn't have can't do that. Right? Yeah. Is the other permission denied or not? Is there almost a backdoor or a different alternate way for someone to do what you don't want them to do, right, if you're trying to secure it?

Yeah. And and so is that again a case where, like, those other kind of boundaries, or or those other, you know, kind of perimeter constructs that we talked about, like the account structure Right. And the network access, they would also come into play, or is this, like, primarily identity driven access? So it's a interesting, question. And let me see if I can, understand a little bit more, right, is I think what a holistic I'm strategy, I think, requires understanding infrastructure and how things set up.

Right? So the accounts, right, the infrastructure you mentioned, right, whether it's within, whether it's external. Right? And then to that point, right, there are concepts in, you know, AWS and also what you've seen with, you know, some of the vendors out there is how do you build a perimeter with, like, organization, right, which, you know, is a set of accounts. Right?

How do you Yep. Figure out who is who do you trust? Right? Whether it's within your organization as in, like, hey. Like, you and I are in an organization and you have one account I have one account.

I probably will trust you. But if I've never met you before and I know who you are and you have an account outside my organization, I may not trust you. Right? So it's a question of what do you trust, how do you build those the perimeter. Right?

And that factors into how we look at these duplicate I'm permissions. Right? Because if it's, ultimately, if it's something we trust, we create guardrails around it. Yeah. If someone does these actions, right, we can maybe just allow them but monitor for making to make sure people are doing what we intend.

Yeah. But still at the same time, right, like, ensure that we know what's going on in the environment too. Yeah. I'm kind of curious about a couple other aspects of this. So if there's multiple ways for me to, grant access or deny access first of all, do you find that most organizations actually understand that there are potentially, like, overlapping or or conflicting permissions?

That's a really good question. So one of the things I I mentioned in the talk and I think this rings true for me is that I think there's a implied understanding that there is only one way of doing something. Right? Right. So using s three buckets as an example.

Right? S three is a very common resource in AWS to store, let's say It's a gap. A blob storage. Right? Yeah.

Yeah. Yeah. So, typically, right, there's only one way to create a bucket. Right? So the action in AWS is a little bit more technical is s three create bucket.

Right? And, for example, to put a resource based policy to grant access to someone else, right, is s three, you know, put bucket policy, for example. Right? So for those, we expect that if we block or we say we don't want anyone using put bucket policy and I block that permission Yep. Then there's no other way of doing it.

Okay. So, you know, taking a step back to your question about, okay. Well, do people understand this? And I think there's an implied understanding that there's usually only one way to do things. Yeah.

But because there are these, you know, small examples of duplicate I'm permissions, and again, right, from a statistic perspective, there's almost over 18,000 I'm permissions a day. Right? That in your talk, and I, like, I was like, holy crap. Which is crazy. Right?

It's that's a lot for someone to even understand. Right? Yeah. Yeah. Yeah.

Over, let's say, 200 plus services. Right? Yeah. So to understand every single action, right, and which ones are sensitive is very difficult. Right?

So these are, again, examples here and there. Right? And the majority of them do not have duplicates, but the ones that do, right, it breaks our fund I think what I've built this mental model in my head about what I'm should look like Yeah. And what I can expect. So when there are duplicate permissions, that sort of breaks that, understanding I have of how do I ensure I can secure AWS I'm for Yeah.

Like, my AWS resources. It it brings to mind another question that I'm I've always been kind of confused about. It's like, I think a lot of the times when people well, let me step back. I've observed this behavior in some organizations. I'd be curious if you've seen the same, which is, like, you know, this natural tendency as people try to troubleshoot IAM is that like, okay.

I can't access a thing. That's why I start troubleshooting. Right? Right. And I'm like, oh, okay.

It's because of x. I don't have get permission or I don't have list permission or whatever the case may be. Right. And so I try to grant myself that if I have access to the I'm policy to to then, like, you know, make that change. Right.

And little by little, I test this additional permission, that additional permission, and at some point, I'm just like, ask who I give myself star permission and and, you know, like, let me just open up access to everything. Right? Right. And I think a lot of people fall into that trap because, like, troubleshooting the granular, like, line by line to figure out what is the thing that is effectively blocking you Right. It is really complicated.

Right? Right. Right. And and so, like, I'm curious if you think about, like, you know, the fact that there are two ways that something could be allowed or something could be denied in certain cases. Do you think people generally, like, care to understand what is the specific reason that allowed me access or they care more of what is the specific thing that denied me access.

That's a good it's interesting. Right? Because I think, to me, it depends on how someone approaches building. If they're looking at, like, okay, what what permissions do I need from the security perspective to do what I need to do with this application? Or they may be just looking for, like, the allows.

But to your point, right, if they're iterating and they're putting application first, which is common. Right? Because I'm is it's a new paradigm. Right? It's, you know, when people didn't have to configure I'm infrastructure, right, etcetera, for all their applications, you know, an application developer didn't have to worry about this.

Right? And now they're just trying to figure out, like, okay. Right. I may have a deadline to hit. Right?

I'm trying to get this feature that adds a lot of business value. How do I make sure I'm focusing on building this? And, like, if I hit the deny, right, to your point, it could do one permission, one permission, one permission. Right? And it may not like, that takes a lot of time.

Right? And it it's frustrating. I've been dealt with that myself. And then to your point, it's like, okay. Add star.

Everything worked. But, like, now do I sit there and spend the extra time to pull permissions away to get Right. The exact Right. Quote, unquote least privilege, which is very complicated. Yeah.

And and I just think, like, a lot of organizations ultimately don't. Right. Right? Like, they they end up kind of getting to some level of frustration, and then they end up doing star. Star.

And to your point, like, they never really peel it back. Right. It it's it's very complex kind of balancing act where especially during, let's say, like, you know, test development staging phases before something goes into production. Right. It's generally much more permissible and allowed.

It's like, oh, I don't really care if Jason has star permission to do his dev. Like, you know, I care about once it gets to prod. Right. But if I then don't know what permissions are actually required from a quote, unquote, least privilege perspective when I get to production. Right.

Like, that's actually a bad thing. Right? Right. And I think to add to that is it made me think of this. Right?

Is you could have different people could have different types of, like, responsibilities. Right? So there could be one application team that does everything soup to nuts. Right? They own the I'm they own the infrastructure.

Right? Yep. They might care a little bit more. And you could have organizations where an app team does it, and someone else will do the I'm for them. Right?

And then there's a disconnect of what are the true permissions that I may need to put that in to put this application in and not break things. Right? Yeah. Yeah. And that's such a to your point, it's a very hard balancing act of how do I get the least privilege but also make sure I'm building an application properly.

Right? Yeah. And then, you know, to that point, it's not only, like, if we dive in the weeds, it's not just an action. It's like, okay, what resources it access? You know, are you putting condition keys on there?

Right? And how does the security team ensure that these are done to a well enough, right, to prevent you know, it may not need to be perfectly least privileged, but Yeah. Good enough for all, you know, the security holes that should be plugged or plugged. Yeah. Yeah.

Yeah. So picking back up on this thread, I once saw a chart that was, like, actually the flowchart of IAM evaluations to to understand, like, if something was going to be allowed or denied. It was some ridiculous, like, 27 step flowchart and all the different things that come over it, and it's like, you know, is there an account boundary? Is there an, a service control policy? Right.

Blocking, like, all of these things that factor in at various points. And I found it like, I feel like I'm somebody who knows cloud a little bit. Right. Right. Been in working in the cloud since 2010.

Fun fact, I am IAM was introduced while I was working at AWS. Wow. So I actually got to meet with the early product team that designed it. And, you know, nobody at the time could have had, I think, an idea of how complex it was going to get over time. Right.

But, you know, even as somebody who's been there for a lot of the journey and has seen IAM evolve, like, I find it impossible to follow the logic of this thing. Like, unless I'm really doing taking the time to go granularly step by step Right. It's pretty bonkers. Right. I know exactly what you're talking about.

That that flowchart, right, if you pull it up, it doesn't even fit on a slide deck. Right? It's like you to your point, it's like, okay. Service control policies, resource control policies. Okay.

Is there an allows or deny? Right? Is there, you know, attached I'm policy? What about resource based policies? Yeah.

What type of principle are you using? Right? And it goes down the list. And it's to you know, beautiful system by AWS, and it works very well, but it's very hard to understand. Incredibly fast too, by the way.

Like, I think that's one of the things that I took away from actually, like, looking at that chart afterwards. I was like, all of this calculation is happening in, you know, like, not what's smaller than a millisecond? Totally. Right. Yeah.

Exactly. Nanosecond. I don't know. But, like, tiny, tiny fraction of time Right. So small that I don't really even perceive it when I'm making my s three buck, bucket object request.

Right? Right. Exactly. Right. And, you know, manually, it takes me, like, fifteen minutes to even figure it out, like navigate that chart for one decision.

Right. Right. Yeah. And this is happening billions of times per minute across the Internet. Yeah.

I'm kind of curious, you know, the background on the research for your talk today that helped you uncover the fact that there are, like, some of these conflicting permissions that's like, what led you to go down this path? It's it's a good question. So I think it's not a very exciting story. I was actually, I think I was working with or, doing a project and or, you know, helping a team out and was looking at permissions because I was looking at, okay, like, you know, one of the things we're trying to help this team do is probably do, least privilege or figure out exactly what permissions they had. Yeah.

Yeah. And while flipping through these, right, I think, you know, working with app teams. Right? Like, trying to figure out what API calls they're using, you know, what AWS infrastructure. Right?

And realizing that I think it I don't know exactly what service it was, but we also have multiple permissions. Right? Yeah. And then looking through because to your point, right, part of it is, like, okay, how do I create boundaries or effective boundaries for people to experiment with? Right?

Yeah. Is what permissions do I not want people to have? Right? Yeah. Yeah.

Yeah. From a deny perspective and realizing that there are multiple different ways to do something, started, you know, leading me down this path. Okay. And we expanded a little bit. Right?

Again, there's over 18,000 permissions, so we didn't cover all of them. Yeah. But trying to cherry pick and fix single out the ones that we think could have a lot of impact. Yeah. And then, again, from a historical perspective, see what influenced the design choices.

Right? Because, you know, well, I think it was fantastic at developing new services. Right? And to your points, it's wild to think about the scale of I'm and how it covers all these permissions, all these requests. Right?

But, you know, where do these inconsistencies come into play that could make securing I'm a little bit more complex than what it is today? Yeah. Yeah. I'm curious about a couple things, like, from your own experience and your own perspective on this. Like, again, as somebody who's, like, you know, showing my age a little bit older schooling comes from the kind of Cassel and moat network Right.

Right. You know, like, as as a guiding concept that I learned early in my career and it's kind of formative to a lot of my thinking around, security. I've I've, you know, since managed to kind of change some of my thinking about it. But there's a couple things that have always kind of come to my mind, and one is, like, generally speaking in cyber hygiene, one of the guiding principles is, like, the less stuff you have to manage, the better. Right.

And so the more stuff you can just kind of, like, turn off and and walk away from the better. And in fact, like, the worst breach I ever experienced in my career is when we were using a piece of outdated technology that honestly should have been retired and we didn't for whatever reason. Right. But, like, you know, to that point, okay, out of these 18,000 permissions, like, my organization needs probably a couple 100. How do I, like, disable the other 17,500?

Right? Right. Right. And that's it's it's a good question. Right?

Because I think part of it is, you know, there are features available. So it's interesting, right, if we think about different again, this makes it complicated. Right? Is there different levels within an AWS account? Right?

Or, like, your infrastructure resource. Right? So you could have, you know, settings at the organization level, which is, like, multiple accounts. Right? So you could have Right.

You know, service control policies that say, like, I want to, you know, deny everyone from using some AWS service. Right? You can block it there so no one can use that. Right? Or, like, I have a resource control policy that I don't want anyone outside of my direct organization asking my s three buckets or decrypting data.

Right? But then you get down to, like, accounts. Right? Then you get down to, okay, the resource, which has a resource based policy and, you know, different levels of things where settings affect what you have. Right?

Yeah. That is very different from the castle and note perspective Yeah. Description. Right? So I think, again, right, there are ways of disabling to answer your question, there are ways of disabling the other service you don't need.

Yeah. But then a question is like, well, what if you don't know what services you need or will need in the future? Right? Yeah. And that goes back to the okay.

Like, now I need to think of doing the security work as almost a development team and work alongside and figure out how do I iterate. Right? Like, okay. I disabled this service in the past. We don't think people should use it.

But Yeah. It's in reality, it's a dependent services needed by something else. Right? Yeah. Yeah.

Yeah. And then figuring out, like go ahead. No. No. No.

I was just gonna say those dependencies are actually, I think, one of the things that I think would catch a lot of people out. Right? It's like to you know, in in my talk today, we were talking about, logging LLM interactions. Right. Right.

You know, one of the things you discover from the log files is that actually, like, I think I'm using Bedrock, but what's actually firing behind the scenes is Lambda. Right. And so if you don't have Lambda turned on, then, like, you know, Bedrock's not gonna work for you. Right? Right.

And and I think that's an interesting thing because another principle that, you know, like, I learned early on in my career from a cybersecurity perspective is, like, actually, you start with a denial Right. And then you, like, selectively turn things on that you want. Right. And I think a lot of customers would probably think, why don't I just bring that same approach to AWS? And I say, well, you know, I'm a relatively simple organization, and I I I need e c two and EBS and s three and, you know, I need some VPC for networking, and I need data ingress and egress and ingress and Right.

I need IAM because I need some users. But, like, honestly, let me turn off everything else. Right. I'm not using RDS. Let me turn it off.

I'm not using Right. DynamoDB. Let me, like, just, like, hard deny access to all of these things. Do you find that organizations have that kind of approach or not so much? So I've seen a mix of both.

Right? I think, you know, if it's a very narrow use case, I think, you know, a lot of the applications are very similar in, I think, design and architecture, then potentially makes sense to do that. Yep. But I think, you know, part of, I think, the beauty of the cloud is experimentation of Yeah. Having, you know, a cloud provider such as Amazon provide all these different services that solve for different use cases.

Right? Yeah. So, you know, you may first use e c two and host self host everything in e c two, but then it's like, okay. Well, why not use a managed service that could do that? Right?

Let me expand the RDS. Let me expand the DynamoDB. Right? And then I think so then you have to think about, like, okay. Well, what services do I expand and add to my like, pull out of my denial list?

Yeah. I think I've seen it both ways. Right? Like, someone will start with, you know, potentially saying, here's my, like, allow list of services. To your point, it could be a list of seven.

It could be a list of eight. Right? Yeah. And I'll slowly expand past that. Or Yeah.

Some you know, I've seen it where people look for organizations will look for specific permissions and services say, okay. We definitely don't want anyone using these first and starting with more of a allow but deny these specific things versus, like, here's this, like, smaller playground. So I think both work depending on what they're trying to do on this, like, how they iterate. Yeah. And I don't have a fully formed opinion yet on, like, which one I prefer because there are no downsides and, you know Yeah.

Benefits to both of those. Right? Yeah. Yeah. For sure.

And I mean, like, you know, if I said I turned off Lambda because we don't use it, but then I can't use Bedrock as a result of it, you know, that's also like an unintended side effect that is gonna stifle innovation. Right. So that's that's not a great outcome. Right. Interesting.

From your talk today, like, you know, you've got this duplicitous nature. We've got these kind of sometimes colliding things that might, you know, overlap with each other in various circumstances. What are the takeaways though from this is, you know, beyond the fact that a, it's complex and b, there's some of this conflict, like, how does an organization navigate? Right. And you took some of my both ones away.

I think the first couple of things I said was, you know, AWS I'm is complex and Yeah. Duplicate permissions do exist to make it hard. Yeah. And I think, you know, to your point, it's, it's very hard to manage AWS I'm but I think having a good strategy in place and this sounds very generic, but having a good strategy of doing an identity perimeter or data perimeter right using these larger controls that AWS provides helps us that if we even do seize or come across these duplicate permissions, right, we have protections against them. Right?

Okay. And I think part of it is, you know, if you go look for the needle in the haystack and go through all 18,000 permissions. Right? And some of them do really like, some of them are a little more sensitive than others. Yeah.

But I think overall, right, like, having this, like, multilayered security approach, right, of looking at looking at my organizations and looking at, like, overall who has access building these perimeters, right, with these organizational policies. Right? And to your point, right, maybe I just say, like, okay. Here are the services I really want or I really care about. Right?

And if it includes Bedrock and Lambda, then sure. I'll add those in. Right? Yeah. And then trying to create an understanding of the true security implications of those and then holistically securing it, you know, not only from an I'm perspective, but from, like, detection, right, prevention, right, responding, things like that too.

Yeah. Yeah. Awesome. So well, Jason, thank you so much for taking the time to join us today to talk through this and, you know, through your own journey and some of the lessons learned along the way. Yeah.

Any last thoughts you wanna share with our audience? No. I think, you know, I really appreciate the questioning, the questions I should say. I really appreciate, chatting with you and learning about, like, you know, your talk as well. I think, you know, some of the takeaways is, you know, I think my favorite part of this conference was just sitting in the hallway and Yeah.

Or even at lunch or breakfast, right, and just chatting with Yeah. Other security practitioners who are truly passionate about security and learning about what they do. Yeah. So Couldn't agree with you more. I mean, I think in the intro yesterday, one of the things that, Aaron who gave the intro said is, you know, you're you're in this place with, like, 300 of the top cloud security practitioners in the world.

Right. So, like, no better place to interchange and and, you know, debate and dialogue with people who have faced, like, some of these hairy problems at scale with complexity Right. With, you know, sensitive data and all these things to to have to kind of consider. Right. And by the way, balance that with innovation enabling the organization to move forward.

Right? Right. People who have faced similar challenges. So awesome. Well, Jason, thank you so much for taking the time to join us on modern cyber.

For For people who wanna learn more, we will post a link to your talk because it'll be YouTube will be up by the time this goes live. So we'll get that link from the show notes. For people who wanna learn more about your work, you I think you said the name of the firm is Fox Security? Correct. Yes.

It's just foxsecurity.com? Foxsecurity.io. Foxsecurity.io. Okay. Awesome.

We will have that linked as well. To our audience, thank you so much for taking the time to join us on this episode of Modern Cyber. We will talk to you next time. Awesome. Thank you so much.

Awesome.