Tyler Warren: [00:00:00] That is how critical safeguarding your data is. No matter the industry or the size of the company, data is increasingly playing a large role in your business. It's oftentimes the critical sauce to your business's recipe, even with the increasing importance of AI.

Ashish Rajan: Have you heard of terms like network segmentation, IDS, IPS, DLP?

I can keep going on. Some of these terms used to be really common on premise, but we never really figured out what it would look like in the cloud world, specifically in the AWS cloud world. So in this conversation, I have Tyler Warren. He is from the company USAA, where him and his team implemented data perimeter, which AWS has been talking about for some time, but there were not a lot of use cases.

So I finally found someone. By the way, Tyler and his team also gave a good talk about this, which I'll leave a link for this in the show notes somewhere or in the description. But I just wanted to bring this conversation in front of you because they are talking about data perimeter in the AWS cloud using native services like SCPs, VPCs [00:01:00] and the challenges they had.

What was the reason they went down that path? What were some of the things that they found were probably easier starts? Why does everyone at every stage in their AWS or cloud journey need to think about data security? By the way, if you haven't considered this, I would definitely recommend looking at data security as a problem, how you're addressing it in your cloud environments, especially when there are no native DLPs in your case, which is the case with AWS that there is no native DLP.

So these are preventative measures you are able to implement that they were able to take advantage of. So enjoy this conversation with Tyler. And if you know someone who is considering putting a data perimeter on how do I network segment in AWS cloud or how do I make sure that the data is only being sent to known regions of AWS or known AWS accounts in your organization or known hybrid environment, so many layers to this conversation.

I hope you enjoyed this conversation and please do share it with any friends or colleagues of yours that are investigating this space, a data perimeter problem that they are trying to solve in the AWS cloud. If you're listening to this on Apple or Spotify, please definitely give us a review or rating because that helps [00:02:00] more people like Tyler get discovered by us. And we also get to talk to more interesting people like Tyler and others who have been on the podcast before as well.

If you are, however, watching this on YouTube or LinkedIn, please give us a follow, subscribe, maybe even the like button as well. Because that definitely lets the algorithm know that you want to know more about this as well. So I hope you enjoy this episode. I look forward to talking to you in the next one.

Welcome to Cloud Security Podcast. I've got Tyler Warren, and we are talking about something interesting, that's data perimeter. But before I got into this. Welcome to the show, Tyler. I appreciate you coming here, Tyler. Can you share a bit about yourself? What's your career like been so far?

Tyler Warren: Thanks for having me Ashish. My name is Tyler Warren. I am a security engineer at USAA, which is United States Automobile Association. It's a large financial services company located in Texas. I help lead our security engineering efforts across public cloud. So all the major hyperscalers, my journey to cloud security is probably a little more winding, a little different than most. If there is such a thing. I spent the first eight or nine years of my career in non technical roles helping [00:03:00] companies, start companies, did everything that you could do for a small startup. Sales and marketing and product design and warehousing and you name it. I probably did it. I actually didn't do anything technical.

I didn't learn how to code till I was 30. I'm 41 now. So I was a little late to the game, graduated from a coding bootcamp, made a career change started working initially for, as a government contractor for the DOD. Did that for several years before moving on to USAA where I'm at now. Now I've been here for about five years and really kind of right when we started our cloud journey as a company.

Ashish Rajan: Okay. And that's pretty awesome by the way coming from a non technical background, you probably have a very unique perspective of the technical world as well. I really appreciate when. People from other fields come into cybersecurity or in tech in general because you're bringing in perspective that no one else would be able to see.

Tyler Warren: Yeah. There's so much to gain from, especially in terms of soft skills that you get with sales in general, like I wish [00:04:00] everyone should go into sales, like you gain so much experience for having the viewpoint of the customer and like taking that to the engineering side, especially on the security side, where we'll talk about this, but I view our application teams as our customers, like, how can I help my customers be successful?

I think it's an incredibly valuable viewpoint to have. It's helped me especially.

Ashish Rajan: Yep, 100%. And talking about the engineering team and the effort that goes into keeping them safe as well. What are data perimeters? I think it's worthwhile kind of laying the groundwork for people probably would be wondering as to what does data perimeter have to do in this context of cloud security.

Tyler Warren: If you read the AWS documentation, you'll probably hear the phrase pretty often that is, it's a way to ensure that trusted resources are accessed from my trusted identities from trusted networks. What is a trusted resource? What is a trusted identity? What is a trusted network? That's going to depend on context, [00:05:00] but I kind of frame the definition as a set of controls or guardrails to ensure your data is accessed in accordance with your organization's requirements, while also ensuring that your business has the appropriate agility to move fast and grow both of those things, whether it's data perimeter or not, right? Having a good set of controls.

Also in allow your business to thrive, I think are equally important. This is the analogy I like to use and this probably says a lot about where I am in my life is, I have a three year old son. And potty training him right has been one of the, I don't want to say I wouldn't call it fun, but it's been interesting.

But like, when you're right there and he's going, everything looks great. Everything's great. Your guardrails are up and everything's working. The moment you turn around to grab your phone. It's going everywhere, right? And this in this analogy. Your data is going everywhere. It's all over the place. Are you going to be able to go back and clean it up?

The stuff that you missed? Who knows? I don't know. Hopefully. That's the analogy I use. Make sure [00:06:00] you've got guardrails to ensure that your data is only being exchanged with the appropriate partners. I will say, data perimeter is not a new concept. It's been repackaged like a lot of things in cloud with a new snazzy buzzworthy phrase, even though it was white paper that came out in 2021.

So that's over three years ago, in cloud years that's like a decade, right? If you. spent time in an on premise environment. You've probably familiar with things like a firewall or intrusion prevention systems or data loss prevention, network segmentation is the main one that I think most people are familiar with how you ensure that certain parts of your data center can only be accessed from certain places. All of that is still present in cloud. As you still have network access control lists, security groups, firewalls. It's really with AWS and all of the other cloud providers and the services that they require an additional layer [00:07:00] of identity controls, and that's really the biggest difference.

Identity and authorization is what data perimeter in the cloud seeks to address. And anything else, it's an additional layer of controls. It can also add an additional layer of complexity to any solution.

Ashish Rajan: Oh, actually, it's a good way to put it because I remember in the on premise days, you probably, once you're in the network, you can go wherever, it doesn't really matter the identity.

It's primarily the network zones that protected, hey, there's a restricted zone, DMZ, all of that. It doesn't really matter if it was Ashish or Tyler or whoever, as long as you're in there, you basically have access to most of it. And, but clearly very different to cloud.

Tyler Warren: Yeah. The, thick candy shell, right?

Like hard on the outside, gooey on the middle. Yeah. You're totally right. And I do think one of the biggest differences is the controls that are applied in cloud, especially when it comes to data perimeter are pretty coarse grained in nature, right? Think about the use of service control policies or resource policies or [00:08:00] VPC endpoint policies.

You're really trying to be coarse grained with them as opposed to really at least privilege with you get identity policies, right? Think about, hey, I don't want to see principles from this part of my network, accessing resources in this. So it's a very coarse grained approach in nature.

Ashish Rajan: Would you say, was there a gap in AWS? Is that why you guys went down this path as well? And I don't mean in the context of that, hey, is that a security capability that most people should think about, And probably it's not as a service from AWS. It's not like a guard duty or security that you slap on and you can just start using.

I think that's where I'm coming from. Is that why you guys had to look into it?

Tyler Warren: Yeah. So I would say, I don't know if it's AWS trying to address a gap. I would say it's AWS's approach in providing guidance to customers on how to adapt all of them, the existing capabilities AWS offers to the needs of their customers, due to the nature of all the [00:09:00] capabilities AWS gives you, whether it's again, service control policies, permission boundaries, resource, identity policies, such, all of the things they give you there's an infinite way to adapt and twist AWS to your needs, right? If you asked a hundred companies, how do you do?

X, Y, Z, you're gonna get 100 different answers, right? To your point, I think this is not something where you can just go check a box and say, that data perimeter thing, it's done, right? You're going to have to adapt the existing controls available to you to your needs. And that's what I think.

The white paper really tries to address and it's, again, depending on your circumstance, it can be pretty complex.

Ashish Rajan: I'm going to link the talk that you guys had at fwd:cloudsec as well, I think it's worthwhile covering and you guys have been doing a lot more architecture diagram and detail in there as well.

One thing I had a thought of when I was looking at this or listening to the talk. Is this for everyone as in should everyone should do this from day one? A lot of us we're interacting with enterprise, large companies, [00:10:00] massive cloud footprint. Sounds like a great idea for network segmentation and having the data perimeter part, but are we recommending people should do it in the beginning as well?

Cause it sounds like it should be the thing.

Tyler Warren: So what I hope is that if you're an existing company or just starting that you have a top down holistic security strategy. And so I think data perimeter needs to be a first class citizen in that strategy. Is this approach forever? Is data perimeter something that everyone should address?

I would ask you this. If you lost all of your data tomorrow, will you be in business ? For many the answer is probably not right. That is how critical safeguarding your data is. No matter the industry or the size of the company, data is increasingly playing a large role in your business.

It's oftentimes the critical sauce to your business' recipe, even with the increasing importance of AI, which you have an entire podcast devoted to. Yeah. Data is at the center of [00:11:00] all of those workflows. Yep. I was listening to a podcast recently where the guest kind of likened AI security as really a form of data protection, problem, which I tend to agree with.

Yep. Even the OWASP for LLM top 10 calls out several items that are directly related to your data, so poisoning data training sets, right? That's a data perimeter problem. Theft of your models, or any other company assets, that's a data perimeter problem. Allowing LLM's excessive access to data, it shouldn't be sharing, that's a data perimeter problem.

But again, that's all to say data perimeter is just one more layer of your defense in depth approach, right? And so prioritize it accordingly, according to all of the other, risks you're trying to mitigate. But there's no doubt that the concepts can apply to any company of any maturity level.

Ashish Rajan: And I'm glad you called it out as well, because I think you and I are old enough to know that we were called information security before cybersecurity was a thing.

The whole concept was that we're trying to protect [00:12:00] information. It wasn't holistic enough. Then we moved on to cybersecurity as a term, but we start, that is the foundation of what the entire industry is built on. So it a hundred percent like lays it out completely. And the same with AI Cybersecurity Podcast as well.

The data conversation, again, we can't even do that without data. I was going to ask for people who are, after hearing this conversation, I go, okay, I guess data is really important for me and my organization. I don't think I'd considered network segmentation or data perimeter as a thing. And if we were to have a starting point for because you obviously done this in your organization, you've gone through this.

You've gone through different phases of it. And the whole talk was around the maturity you guys have had across the board after you started from the time you started the challenges you had. And what do you think is the next step? I'm curious for people who are starting. Feeling inspired by I heard Tyler.

Okay. I'm going to, I'm ready. I'm going to start doing this. What would you say is a good starting point and you throw SCPs in there, organization in there. So what are some of the components are moving parts that they need to look into for [00:13:00] implementation?

Tyler Warren: Yeah. I think it starts before you even are hands on keyboard and that is as a company really try to identify, do a threat analysis on your environment and a risk assessment and identify the gaps where you feel you don't have the appropriate controls, right? Where are the places that you can most quickly pay down risk and start there.

Obviously the calculus is going to be dependent on your risk tolerance as a company, industry, the regulatory and data privacy requirements. But I would start there. I think talking to folks about this, the folks that have been successful, really try to use quantitative measures in large part because it reinforces the effort to your business partners.

And I'd go back to what I said previously, like having your business partners on board. Is much of the battle. And so I would start there first. And in parallel, if you're looking at your AWS organization and your data, [00:14:00] identify the zones of trust that matter to you. Where is your data located? Who is accessing it?

And where is it landing? And so identifying those access patterns and what data is crossing those zones of trust within your environment. It is probably the first step before you start crafting any automation or any policies. It's also the hardest step, I would say, given that there is essentially a lack of telemetry available out of the box to you, right?

If you have a data set at your disposal, whether it's an S3 or Dynamo, RDS, wherever, very difficult to identify the users or roles they're accessing that data and where it's going. Like you do have CloudTrail. There's nothing in your CloudTrail log that says hey, this cross one of your zones of trust, or there are access patterns that aren't even logged by default.

And so you're gonna be playing with a little, it's a little more murky than you would like. And so that's going to be like the next step before you [00:15:00] start implementing and rolling out policies.

Ashish Rajan: We're in this episode for a special mention for our sister podcast, AI Cybersecurity Podcast. Yes. If you want to know more about the primer for LLM, AI, and all the acronyms that float around, what do you really need to know as a cybersecurity leader or practitioner in this field? That's what Caleb, yes, I have a co host there who is equally smart and talented and currently is the chair of Cloud Security Alliance, AI safety initiative.

We both talk about the cybersecurity challenges of AI. What are other CISOs doing? We had the CISO of Athropic, the CISO of Deepmind and a lot more other people who are trying to solve the security for AI and whether it is AI for security. You can find us on all the audio video platform, but also on aicybersecuritypodcast. com. Now back to the episode.

Actually, it's a good point. Because, I kind of threw the world of DMZ and restrictive zones on all of that. What are the boundaries?

I think it's worthwhile calling out, people may not even understand what would be a data perimeter scenario, which would easily define boundaries, because I think the example you gave earlier that, hey, AWS [00:16:00] account, is it mine? Or is it my personal one? Or is it the actual organization one?

Like something as simple as that? What are some of the examples that come to mind? So people understand the boundaries to start defining zone of trust, like what would be, Okay. An example of a zone of trust.

Tyler Warren: So I think what is a zone of trust? And I think we've I will say our team has probably stolen it from Access Analyzer.

They use it to identify access that's outside of your account or outside of your organization, right? And so we've taken the phrase to mean we use it more broadly to describe areas within your organization, likely parts that are, at the OU level where you want to harden your controls and limit access for some reason, it might be business critical assets that you want to only allow internal customers to, it might be regulatory requirements like PCI data, like that could be a zone of trust, right?

But just in general, the first ones you probably think of are my AWS versus not my AWS, right? You might, probably might also [00:17:00] think about internal zones of trust. So production data versus non production data. I don't think there's too many use cases, especially when it comes to a large financial services institution where you want to mix prod data into your non prod environment, right?

That's typically not a good practice, but I think that applies for most people. There's also, again there's PCI requirements. There's other regulatory requirements that can drive those discussions, but it's really about really I think of them mostly at the OU level.

Ashish Rajan: Ah, I see what you mean. And I think it's worthwhile calling out as well that I think what we are referring to here, these are prevention controls. These are not detection. We're not trying to detect this is happening. We just want to stop that from happening in the first place.

Tyler Warren: Yeah, I think they can bleed into each other, depending on how you organize it, right?

You can say, I should never see this type of pattern. And then you can go create a detection on it. I think it's really helpful to draw a line between here's a control and here's my preventative, here's my detective, whether that's some [00:18:00] internal detection or Access Analyzer, and then some corrective action.

Maybe you have automation that goes and updates a policy like that's been changed out of band like so drawing the thread between all of those is important, but you're absolutely right. Whether it's SCPs or endpoint policies or resource policies, they're typically more preventative in nature.

Ashish Rajan: Yeah. And to take this a step further as well. You called out the organization, there's a whole AWS organizations and SCPs you called out as well. That could be the difference. I've been in organizations where we had multiple AWS organizations as well. So people who are thinking about this from like a layer deeper.

You're primarily looking at defining zone or trust at an AWS org level using SCPs.

Tyler Warren: SCPs or endpoint policies or even resources. I think it depends on the maturity level of the customer, right? I think most medium sized companies are probably already using SCPs or permission boundaries. Like they're already using elements of data perimeter.

I think really taking a step back, seeing where [00:19:00] they are, seeing what they have and where they can fill those gaps is probably like the best way to start. And that a lot of that is driven by your org hierarchy. Like best practices for AWS is not to structure your org like your HR diagram. It's structured and organize your accounts under OUs where you want to apply similar controls.

For data perimeter, it's really the same thing is, hey, I want to apply a set of controls around this OUs for various reasons. And that can be SCP. That's probably the 1st place. Most people start because it's the most mature, I think, but it also involves, things like when we talk about resource policy, how are your developers actually rolling out resource policies. How are you adding controls there? And so all of those things, the ways you do business and your org kind of roll into your strategy.

Ashish Rajan: I learned something there as well cause I think initial perspective that I had was primarily revolving around using SCPs for it, but you called out VPC [00:20:00] endpoints, resource policies, I think Meg did a good talk as well on it, so I've got an interview with her on the entire VPC endpoint policy challenges and fine grain, course grain, that was I imagine, I think in your talk also you called it out as well.

That was a relevant talk, which kind of brings back the whole data perimeter perspective as well.

Tyler Warren: Yeah, it was a great talk. There is a lot of different philosophies when it comes to what level of maturity you start managing endpoint policies, for those that may be less familiar.

They, when you spin them up, there are allow all by default, right? Which is, I can understand the motivation why, you don't want to break something. They're, I won't call them new, but they're newer than some other, especially interface endpoints are newer than some other controls.

But yeah, how you organize them within your org is really interesting. And once you get into managing policies, that's where you really have to make some decisions.

Ashish Rajan: Yeah. And maybe just to bring back one more point where you said hey, the conversation about data perimeter even starts before your [00:21:00] hands on keyboard even happen.

Is there like an exercise you had to go through with say, and maybe inspiration for other people? Cause talking about business partners, talking about AppSec people or applications developers, I almost feel like what you're also referring to is that there needs to be an understanding of what is like, there is an information security policy in the, but then there is a policy that's followed versus just understanding like which one applies to the cloud versus which one applies to on premise.

Like we haven't even spoken about hybrid environments yet. How does this play out in hybrid environments?

Tyler Warren: Yes. The way I would define hybrid, and this is key, I think there's like difference of opinion to here is, in general, I think of a hybrid network as two or more different platforms that need to exchange data.

That could be brokering access between two different cloud providers, right? Like most large companies are multi cloud now some even by choice, how do you broker access between an on prem data center and, or a colo with one or more of the CSPs, you've even got large SaaS platforms [00:22:00] working their way into that conversation.

What point do you consider them kind of CSPs, that kind of philosophy. But I would say when you're talking about how API calls are made and identities used. If you're using endpoint and VPC endpoints, a lot of those calls will stay on AWS as network. But if you are making cross region calls, those will take the default route out.

If you're using services that don't support private link or maybe you're making calls to another vendor who's not in AWS, although that's going to take the default route out your network. And so while we talk about data perimeter items in AWS, hopefully part of your larger strategy is addressing that other default route.

How are you putting security controls around that default route that your calls are taking? If you're in, an on premise environment, you hopefully have those calls traversing your network stack, where you might use things like firewall or data loss [00:23:00] prevention. That's the first thing I would think about if you are in a hybrid network.

And then, how do you broker access between, your Colo and your AWS tenant? Like how were calls coming in? Like, how are you leveraging AWS identities in those hybrid applications, and that's important because it's not just a security concern, but it's a scalability concern. Are you using OAuth and JSON Web Tokens, or you're using X 509 certificates for your machine identities, things like roles anywhere really shines here.

But that puts a huge premium on secrets management, in your on premise environment. How are you effectively managing through your colo and data center? There's things like, expecting partners from various cycle ranges, those tend to be, at least nowadays, a little more dynamic.

So maybe you're using mutual TLS that authenticates not just the client, but the server. And so there are some considerations there. Then, of [00:24:00] course, we also got DDOS and botnet mitigation, things like that.

Ashish Rajan: Would you say, as you have gone through this journey, obviously there's so many moving parts.

There's the whole hybrid network. And then there is hey, it's a multi cloud. Then there is the concept of what is my zone of trust. There's a lot of work involved in the beginning. And I clearly don't imagine it happened in one week, took a few months or years as well. In all of this, I think in the beginning, were there some challenges that you guys came across?

Now, obviously I don't think it ever finishes building. Because we keep adding more products and kind of things, it keeps evolving by its own. What was some of the challenges in the beginning? I'm curious because I wonder people who are listening in were very inspired to do this on their own.

Yes, there is a possibility that technically this is possible. What are some of the challenges that you had, either from a getting people on board perspective or even actually technical as well, if you had some.

Tyler Warren: Man that's a big question. We could do an entire 45 minutes just on lessons, but I think, no, I do think the things that I think have led to [00:25:00] successful deployment of these strategies, whether it's things that we've learned or things I've learned from other companies again, I will just put some of the impact of communication.

And how it can have impact your speed to roll out is incredibly important. Your business partners have to be part of the process. They need to be aware of your goals because there's a lack of telemetry. There's a higher risk of causing an outage. What I can tell you is you can use that to your advantage in a lot of ways.

And that is, Ashish, if you've ever probably bought a product, you've gone home, you've been excited and let's say it broke. And you call them up, but it was great customer service and they fixed it right away for you. And in some ways, again, going back to my previous experience in sales, when you have those situations, you can reinforce the belief in your org and your priorities by helping your customers fix their problems.

And so I think that is one of the lessons that I would tell everybody to take, communicate and make it easy for people to [00:26:00] complain to you. It's a customer service problem in a lot of ways. I would say the second thing is being able to manage exceptions at scale is really important. You're never going to get every access pattern logged or things like that.

And so being able to point to a piece of documentation or process to your team to say, Hey, if you need that thing, go do it this way. What we've tried to do, and I think this has been successful is we have all of our controls. Version controlled and we have them, our application teams know about them.

If they want to request access, they can go make a pull request in those repos. And then a lot of ways it takes our security team, which is small, but mighty out of the critical path. And so I think that's really important. We don't have to, you don't have to write every policy for application teams.

They can do the brunt of the work, but if they follow our standards, we can just review it and roll it out. Once it's been approved. And so that's really easy. You asked about, things that we've learned. I think 1 thing that's been [00:27:00] really eye opening. And I think companies that are going through a digital transformation will also experience this is the rise of what I would call shared services. And those are things that every application that you service in your org might need to access at one time or the other, we probably didn't do a good enough job of thinking about where we wanted to put those in our org hierarchy, and so we are now trying to pull those out from those very hard internal boundaries into another OU, and you have to think about those shared services as you're migrating applications from, your on prem environment to cloud. They're not just servicing your cloud applications, they're servicing all of your applications on prem. Do you want to start poking holes in that hard boundary that you thought you think is really important?

Probably not, right? And that is probably the highest kind [00:28:00] of like priority, I would tell people, hey, you probably haven't thought about it, but really think about this. Think about where you want to be in three or four years and start organizing your accounts, maybe differently or thinking about them differently.

And the last thing operationalizing Access Analyzer. That is huge. You're going to see the number of resources in an organization as you grow. That number is going to grow exponentially. It's going to get into the millions pretty quickly. And so analyzing those kind of resource policies and access patterns at scale is really where Access Analyzer shines.

Ashish Rajan: I guess to your point, I wasn't aware it can actually do, can it still do multi account as it looks after everything? It just looks across your entire AWS footprint? Access Analyzer?

Tyler Warren: So it will look at resource policies at two levels and say, you are allowing access to this resource by an identity that's outside of your account.

That's one. And then you're allowing identity, sorry, you're allowing access to an identity outside of your [00:29:00] organization. And you can think of that as public, right? You're making something public. And so you've got those two zones of trust that Access Analyzer. Reports on either of them might be equally important, but I would definitely say that public access that Access Analyzer can highlight is very important, especially if you've got developers that are just new to cloud and onboarded and they're building quickly people make mistakes.

And so that can be the first line of defense and highlighting those and addressing those gaps.

Ashish Rajan: And so it's funny because we had a conversation with Bridget Johnson. She's the GM for Access Analyzer. They're adding a lot more capability into it. So it's pretty good to know that there's actually it does go across quite a few things.

I was gonna say in terms of shared services that you called out that would became a challenge for you. Was there, obviously that's a byproduct of working in a digital transformation space. I think you also mentioned shared data layers as well, because I, so I'm curious if you can appeal a few layers on that shared data layer as well.

Tyler Warren: Yes. There might be. Data sets that [00:30:00] you want to expose to certain customers or your entire org, or you want to limit to certain customers. And so I think organizing those data sets in the right, Oh, you, where you can add light controls. If it's a, a publicly facing data set, you're going to have that in hopefully some sort of what I equate to like DMZ like account.

And that's going to be a very separate set of different set of controls around those versus your internal data sets. And so again, going back to how you organize your controls and your org hierarchy, you're gonna have very different ways to allow access on each. You've got the idea of shared services, examples of that.

that we've seen are things like publishing golden AMIs that you want to use the org, things like security agents you install on VMs, or maybe you use Amazon's private CA to vend certificates. You want that available to at least parts or all of your org. Things like, and it makes me shudder when I say this, shared [00:31:00] API keys, right?

There are certain vendors that want you to share an API key to access their services. Yep. They know who they are. Won't call them out. Hope it changes. That might be something that you want to share across your org. So separating whether it's datasets or even those servicers. I think of them similarly.

And are they going to be accessed by all of my org? Okay, that might have a different set of controls.

And are they going to be accessed by a subset of my org? There are different AWS condition keys that you can use for each of those.

Ashish Rajan: I'm glad you called it out as well, because it's probably sometimes hard for people to judge the maturity of where they are and whether some of the tactical questions that I have from this is that which environment am I, should I start this in dev, test, prod, like, where do you recommend people start with this?

Tyler Warren: So if you are at the point where you are rolling out controls like more restrictive controls. Don't YOLO it and prod like that. Please don't you're not going to have too many happy customers. [00:32:00] I would say that the tact we took and I think the tact that's made the most sense talking to others is rolling out progressively throughout your environments.

So again, maybe you have different staging or non production environments. Roll it out there first. We allowed bake in time, like anywhere from days to weeks. And then we also, as part of our migration identified what we consider higher risk customers and said, hey, can you go validate this?

Things are still working as expected. And we did that throughout all of our rollout, even into prod. And so that's probably how I would say you want to get started. Now, what type of controls you're going to roll out, like how restrictive what zones of trust that can vary, but I think holistically rolling them out through environments is easily the best way to go.

Ashish Rajan: And is there a recommendation on starting with, we obviously called out the resource policies, VPC endpoint policies, and I think is there an easy or a hard one to start with from a tactical perspective?

Tyler Warren: I think [00:33:00] SCPs are probably where most people start. Address your organization's users and roles.

And I think when you talk about data perimeter, part of the question is my controls, are we worried about external threats or internal threats? I think SCPs can really add those hard external boundaries. Blocking public access for ECR or S3. Like those really hard controls are the first place to start.

Those are like the easy wins, I think. Yep. Or organizing your SCPs to where you block public access in certain areas, but maybe you have publicly exposed stuff in another area. Those are the first places to start. I think you can then start to graduate to, okay, I do want to allow certain access between zones of trust, or maybe I want to not allow actions between zones of trust, and you start getting there a little more, what I would call, little more fine grained in nature as opposed to just a box around my AWS versus not, those internal zones of trust.

So I'd start there. I think [00:34:00] endpoint policies are probably more of an advanced maturity level, just because of, SCPs they don't affect other organizations, users or roles, right? They don't affect service linked roles or service principles. VPC endpoint policies do impact every identity that's used over that endpoint policy.

And so there's a lot of gotchas that come with endpoint policies. In practice, I think you only see. allow statements in endpoint policies because if you user deny, you're probably inadvertently blocking some access that you didn't intend to block. So I think that's a little more mature. Resource policies, I would start with SCPs.

That's probably like layer zero, making sure that, how you enforce certain policy standards with, whether it's a preventative or detective like access analyzer. I would consider that, a starting step with SCPs.

Ashish Rajan: And how often would you review them? Because organizations move quite quickly as well these days.

Tyler Warren: Great [00:35:00] question. I think if organizations are growing their cloud footprint, you're going to find that your security teams are probably tweaking your SCPs often. As the needs of the business change as more, bespoke use cases are on boarded. I think you're going to start tweaking those pretty often.

I think resource policies get tweaked more often. You have things like roles that need access to every bucket, right? Or every KMS key, things for backups or incident response, like those get updated pretty often. Yeah. What I think is maybe a better goal to have is having a periodic review of those public accesses that you allow or access to external actors, things like, allowing vendors to do things in your environment or allowing your principles to access vendors.

Are those still needed who are the point of contact for those kind of things like tagging can really come in handy there at the account level or the resource level to identify those people of interest that you can coordinate with, but [00:36:00] that's a huge, I think part of data perimeter is just life cycling those kind of policies.

Ashish Rajan: And would you say in terms of investing time and effort into this as well, obviously, you're leading a team, what kind of skill set am I looking at in my team as well for this?

Tyler Warren: That's a great question. I don't know what probably people think of as cloud security.

What kind of skills to me, it's almost like what's a data science. Data science is now programmers and people who familiar with some of those tools. Cloud security really is equal parts, at least on our teams, they are equal parts programmers. You got to have programming background.

I think in many ways, you've got to have, security background, obviously you've got DevOps experience, right? Especially if you're using CICD and preventative controls, like DevOps is really important there, then you've got like operational experience, right? These tools are these things that are always running in your environment.

They need to be running 24/7. You need to have on call [00:37:00] support, right? When things go down and aren't working, you've got to, you might get a call in the middle of the night. So it's a combination of all of those together, plus probably some I'm missing plus the soft skills that come with customer service.

I think those are, You've got to take those into account as you're building not only a data perimeter strategy, but you're just security organization in general. And there's just a lot there to unpack.

Ashish Rajan: And because you mentioned CICD pipelines, the reason I was asking about that skillset question specifically now was also because the complexity of technology that comes across I think there's CICD pipelines, there's working with SVCs.

GitHub, GitLab, Jenkins, just throw every open source spanner out there. And in a fairly large scale environment, there's a more growing need for things to be developer friendly. And so far we spoke about SCP, VPC endpoints policy and all of that. I don't know what's a easy way to answer, apart [00:38:00] from just asking, is it developer friendly?

Am I gonna be fired by by a developer who's just angry because I removed their access to something super important.

Tyler Warren: That's a great question. Something we think a lot about I think in order to be successful, you've really got to go to where developers are going. Try to add security to the easy path.

What do your team's typical day to day workflows look like? And can you bake some of those controls into their workflows? Hopefully you can do it transparently where they don't even see the difference. I think of CICD is probably the biggest benefit here. I look at a CICD pipeline as like a hanger and you can hang all of these different things and things like you can use infrastructure as code and then things like infrastructure as code scanning tools, whether it's OPA, Or Chekov or TFSEC, whatever it is.

You can do things like cost analysis, like cost impacts. You can do, bake in your SAS tools in there. Like those things, [00:39:00] I think, and I hate the term shift left because it's taken on, it's the most cliche thing to say. I think most people that use it don't see the impacts, right? But if you can bake it into your developers workflows by default, I think you can actually pay down risk with very little, impact your developers productivity.

And I think you can make them more productive in some ways. And so improving that experience, even automating things that weren't automated, like that's a huge blocker for a lot of organizations is I've got to go through this manual step. I need to get reviews from certain people.

Can you automate that stuff? Can you use some sort of workflow or ticketing system to have that move a little quicker. Like those are the kind of things that like, if they're not done well, you're going to have either blocking the business or sometimes worse, you're going to have developers find ways around those tools.

And that's a bad place to be too.

Ashish Rajan: Very well said, because, yeah, I definitely believe most of the applications we're working with, our customers are technically developers are producing it [00:40:00] to going back to what you were saying as well. At the end of the day, if they're not happy, then, we're definitely not going to have any progress, irrespective.

As you were going through this and we spoke about the challenges we were talking briefly about preventative and detective controls as well in terms of the team skill set and like the amount of effort that was required for preventative and detective control. Were there challenges faced there as well in terms of technical challenges or any other challenges you faced?

Tyler Warren: Yes, I think analyzing resource policies at scale is really hard. . We lean on those CICD scanning tools like OPA, but I haven't found a tool that can catch every edge case. There's always things that we'll get through. I think one of the things we really tried to do was, hey, let's get to, what's the 20 percent of effort that can get us 80 percent there?

Like, how can we get the biggest bang on our buck for our time? And we've tried to catch all of the edge cases we can, but then we [00:41:00] compensate the lack of maybe that last 10 percent where there is a law, the diminishing returns in your investment, really use access analyzer there to catch those really egregious violations of policies.

I think the reverse is true on detective controls for access patterns. Like it's really hard to add alerting and monitoring on certain access patterns, right? Like things are always happening. New use cases are being onboarded. You might not have up to date monitoring and learning, and you're getting a lot of false positives for a new access pattern, right?

That's a really hard thing to do at scale. And I think one of the areas I think the industry is going is really looking at things like data security posture management tools or CIEM tools that can identify that anomalous behavior or, toxic pairs and things like that, that you can start detecting on and remediating ahead of the fact.

And so I think [00:42:00] those are the 2 places where I think have been really tricky. And I think there's a lot of room to go on the tool sets available and then operationalizing them in various environments. So that's one of the areas I would probably highlight the most.

Ashish Rajan: And anything that worked in getting all the business stakeholders on board onto this journey as well, I'm going to go shift left over here again.

It's like in that kind of world, people talk about the fact that, hey, find the friendliest team you can work with to start off at least proving the concept and then use that as an example to move to the next team and so on. Was there any things that you found that were helpful in getting the stakeholders who may perhaps a bit hesitant in the beginning to have them on board?

Tyler Warren: I don't believe any application team wakes up and says, you know what I don't care about security. You're like, no one actually says that, right? What I think, and this is, I think you had Chris Farris on recently, and I think he made this point, which I totally agree with when you're talking to application teams, aside [00:43:00] from using data, if you can, those quantitative measures, if you can point to a real world breach and say, hey, Okay.

These are the kind of things we're trying to prevent and here are the controls that we're gonna help you add. And we're going to be right alongside you if you can show them that real world example of millions of dollars in fines or whatever the outcome is. Yeah, that to me is more impactful to a development team than just saying, Hey, go do this thing.

Here's what we're doing. And guess what? Your boss said, we're doing this. So you got to do that's not at the end of the day, it's the developers who are hands on keyboard doing this stuff. Like you've got to, you've got to show them that like you're in it with them. As opposed to just, sitting on this ledge above them and saying thou shalt, do these things.

I don't think that's an effective strategy.

Ashish Rajan: Yeah, and I probably would add one more thing here as well, as you were saying it and what you mentioned made me also think about the fact that if these kind of preventative controls do exist [00:44:00] and you can sprinkle some detection control as well, the overall burden on your own cloud security was low as well, or, over time, because all the CSPM tools and everything else, a lot of false positives, even from the native tools as well.

So this could potentially just be good for your company to start doing this, just to reduce the workload overall, right?

Tyler Warren: Yeah, if your only way to scale as an your security organization is to add headcount, I think you're setting yourself up for failure. Show me a company that's got unlimited budget to hire security, like they don't exist, right?

The mantra is do more with less. And I think the only way, To even make a dent is to use automation, like whether it's even those tools, like you mentioned, whether it's CNAPP or DSPM, there's a load of them, even operationalizing those things requires an upfront investment from the business, because like you said they can add a ton of false positives and add even more work to your plate, right?

Like before you start seeing the value. [00:45:00] So I think you've got to use automation, but you've got to be up front with your business partners around. Hey. Here's the type of investment like we're gonna have to make and headcount. We're gonna have to devote to it. We talked about, some of the large SaaS providers to there is some of these large SaaS providers that are built on the hyperscalers.

They have their own IAM constructs, right? You've got their own abstracted form of compute and storage. If it starts talking like a, cloud service provider, if it starts walking like a cloud provider, it might be a cloud provider, right? I'm curious to see how that plays out in the future and at what point does a security team say, hey, you know what, we're going to have to treat this like our other tier zero hyperscalers in the security rigor that we require from them.

I'm really interested to see how that plays out because I think that's one of the future items that I think we're going to see.

Ashish Rajan: Yeah, I think it's a good point because you almost feel like the AI kind of kicked off a lot of these SaaS providers where you're in this, like you've fed so much data into it, the [00:46:00] models being built in it, there is like hooks into every cloud provider as well, putting data.

It's almost like you thought your AWS environment was very crown jewel, but then there's another one, which just happens to be a SaaS product as well. Yeah. Seems to have equal amount of sensitive data in there.

Tyler Warren: Data Printer is not just, again, about your AWS tenant.

It's about your on prem environment. Like a lot of these SaaS providers, you can take your data and you can send it to other vendors through that SaaS provider, right? So there's additional considerations, especially when it comes to data perimeter around what does the authorization authentication mechanisms look like there?

You can run Kubernetes and Snowflake now, right? The complexity is only growing, right? And so having that overarching strategy, that's cloud provider agnostic or platform agnostic, I think is really step zero, like we talked about for any maturing organization.

Ashish Rajan: Yeah, and I guess the final question from a [00:47:00] technical perspective is, if people who love the whole levels of maturity Hey, I may be level one today because, you guys spoke about AWS organization, SCP is a good point to start, maybe resource policy attached next to it as well, but then you move on to the VPC policies and everything else.

How would you describe the maturity, at least in the experience you've had so far? What's a good maturity kind of thing as, Hey, this is a good starting point. And starting point level zero is you don't have any of this. And level one, what would that level one look like? And what could be level four or five that perhaps you're aiming for in the future?

Tyler Warren: Yeah, great question. I think baseline maturity, I would characterize as you've unidentified your internal versus external access, like that zone of trust. And you started locking that down with SCPs and other controls. You've probably, hopefully started with, hey, these are the services where I have my crown jewels for a lot of organizations.

That's S3 typically. So start [00:48:00] with that service and how you're adding controls via pipeline or console might start there. And then hopefully. Like we talked about, you're using some sort of IaC, CICD to bake in your security best practices there. You might have some IR playbooks there, hopefully, but they might be manual, right?

I think you graduate up to maybe medium by identifying additional internal boundaries, right? And adding controls at those levels. You've expanded the controls around additional services that maybe even store data or move data. I think you probably have more robust controls and detective controls there.

And then you graduate to the advanced level, which, I think this is where the immaturity and some of the tools we have, but you're probably hopefully I would love to get to a point where you're feeding changes in your access patterns in real time to your detection stack, right?

So you can update your detections as new access patterns are brought [00:49:00] online. So you don't have those false positives. I think you're probably, adding detections through again, some of those SaaS providers likely or I think like new AWS services for toxic pairs, highlighting that anomalous behavior, using IAM policy suggestions more frequently.

And then you probably have, hopefully pseudo automated incident response playbooks to clean up access that shouldn't be there. So I think of those as the three kind of levels right now of maturity.

Ashish Rajan: Thank you for sharing that. That's most of the technical questions I had.

I've got three fun questions for you as well. First one being, what do you spend most time on when you're not trying to solve cloud security challenges in the world?

Tyler Warren: So I am, I'm a huge basketball fan. That's my jam. I live in San Antonio, home of The San Antonio Spurs. I probably watch 75 out of the 82 games a year.

Oh, wow. Okay. Yeah. I'm a weirdo. No question about it. Like you want to do a podcast on basketball? I'm your guy. So I do a [00:50:00] ton of that. I, again, I have a three year old. That's a ton of my time. It's awesome. I've got an awesome partner too. And my wife but that's where the bulk of my time spent right now.

Ashish Rajan: Interesting. Although this is not the question I'm curious to ask. Between LeBron James, Kobe Bryant, and Steph Curry. Who would you rank? I know it's a super hard question only because you mentioned NBA and I'm like, Ooh, I wonder if you have some thoughts on on these four people who seem to, at least I seem to keep coming across them.

I love to watch them play. I love watch their games as well. Obviously Michael Jordan and Kobe Bryant are a different story, but. Do you have a preference order there or who's your favorite NBA player at the moment?

Tyler Warren: Man you're setting me up to get flamed, I think. This is a setup.

Ashish Rajan: It'll be funny if you and I are the only people who enjoy NBA, the entire cloud security, then it's

Tyler Warren: No one cares.

Ashish Rajan: Yeah.

Tyler Warren: Who is my favorite

Ashish Rajan: Who's your favorite, living or dead? Irrespective, who's your favorite NBA player ever?

Tyler Warren: I grew up, I was born in early 80s, right? So I remember [00:51:00] watching Jordan in his heyday. I remember watching the first game when he came back from playing baseball.

I remember that watching him go through the Knicks was, all the beating he took. That's one of my first kind of like memories of basketball. I went to a bunch of games when, Spurs were on the rise. I would say my all time favorite player. Again, I'm partial to the Spurs is Manu Ginobili because just the passion he played with the, just the dedication, just he would do anything to win.

I think you can see the same thing in players like Kobe and LeBron, which is why I love watching them or loved watching them play. Out of those three players you listed, like I, I think LeBron is clearly head and shoulders the best player. Arguably the best of all time. I don't want get into that conversation because that's like

Ashish Rajan: I know. Definitely some flame setting conversation.

Tyler Warren: Yeah. We will get aggregated, I'm sure.

Ashish Rajan: Yeah, no, but thanks for sharing that. I'll probably put a pin on the NBA one to continue another day. The second question I had was what is something [00:52:00] that you're proud of that is not on a social media?

Tyler Warren: Man, I would definitely say being a dad. I think that's I was, I've had so much fun over the last three and a half years. His artworks right behind me, he, I mentioned in the top, potty training. It's a wild experience, man. It's my house is one big episode of naked and afraid, like he's naked and we're just afraid.

That's pretty much what my life is right now. He's awesome. I have a ton of fun. Again, I have an awesome partner. My wife is amazing. She goes from teaching first grade and 20, 20 kids to like coming home to him, which is, I don't imagine going from your job, you're a hands on keyboard every day, going home, and then that's what you have to do.

That's your fun, right?

Ashish Rajan: Yeah, I can't imagine a much more personal level as well. It's like this actually feels, it hurts every time the person is upset. You're like, what's going on? Like you can't have that separation of boundary as well. At that point in time.

Tyler Warren: Yeah, so she's amazing. She's so much better at her job than I am at mine.

It's stupid. But she [00:53:00] is one of the, most important people in my life. And my son are the most important people in my life, but she's a huge reason why, you know, it's been so much fun.

Ashish Rajan: Thanks for sharing that. And final question, what's your favorite cuisine or restaurant that you can share?

Tyler Warren: Oh man, that's a good one. I would say I'm from South Texas. So Tex Mex is right at the top. I could eat that every day. I don't, cause I wouldn't be alive for very long. I gotta spend a few more years for sure. I'm, I will tell you this, I love Indian cuisine. I love italian cuisine. My big thing is, wherever I am, I want to go eat where the locals are. Like, that is my thing. What are the locals eating? If I'm in, whatever new city that's what I'll ask people to do. And I'm pretty open. I think, San Antonio's got a great food scene. But others have, that's our thing, me and my wife when we travel.

But I would say, to answer your question, Italian. There's not a pizza I've ever disliked.

Ashish Rajan: Really? Wait, so [00:54:00] between, see, this is a New York pizza or a, what? Okay, yeah. This is, again, I think this entire episode is now being on NBA fire and pizza fire, pineapple in a pizza conversation.

Tyler Warren: I celebrate all the pizzas.

I do not understand people that get so worked up over fruit on a pizza. Who cares? You know what other stuff goes on pizza, anything goes on pizza.

Ashish Rajan: To be fair, Italians did add chocolate onto pizzas. Like the calzone is supposed to be like Nutella and chocolate. So I don't think it's like a sin to have that.

Consider the people who started the whole thing. Don't mind it. So I don't know why the rest of the world cares as much, but I'm going to, again, pin it, I'll probably talk about this with you when hopefully get to meet in person soon as well, but where can people find you on the internet so they can connect and talk more about all of this?

Tyler Warren: Yeah, so I'm on LinkedIn. That's an easy place to look me up. I'm on Twitter or X @jtylerwarren is [00:55:00] my handle. I don't do a ton of commenting. I'm not the most active. I'm a watcher. I'm a silent browser. So that's probably also the easiest way to get ahold of me.

Ashish Rajan: Awesome. I'll put those things in there as well, but thank you so much for coming on the show. I really appreciate this. I think it's been very valuable. I got to know so much as well, and I'll put your talk on the show notes as well and the description. So people get to hear that as well, but thank you so much for coming on the show.

I look forward to talking more to you about data security, data perimeter, how we go further from this as well. Thanks so much for coming on the show. Thanks Ashish. Thanks for having me. Thanks for having me talk about NBA as well. I appreciate that as well. Thanks.

Thank you for listening or watching this episode of Cloud Security Podcast. We have been running for the past five years, so I'm sure we haven't covered everything cloud security and if there's a particular cloud security topic that we can cover for you in an interview format on cloud security podcast or make a training video on tutorials on cloud security bootcamp Definitely reach out to us on info at cloud security podcast or tv By the way, if you're interested in AI and cybersecurity, as many cybersecurity leaders are, you might be interested in our sister [00:56:00] podcast called AI Cybersecurity Podcast, which I run with former CSO of Robinhood, Caleb Sima, where we talk about everything AI and cybersecurity.

How can organizations deal with cybersecurity on AI systems, AI platforms, whatever AI has to bring next as the evolution of ChatGPT, and everything else continues. If you have any other suggestions, definitely drop them on info at CloudSecurityPodcast. tv. I'll drop them in the description and the show notes as well.

So you can reach out to us easily. Otherwise, I will see you next episode. Peace.

‍