Ashish Rajan: [00:00:00] Hello, welcome to another episode of Cloud Security Podcast. In today’s episode, we have Travis McPeak from Resource Lee talk about building a cloud security program. He’s using his experience at Netflix and other places to talk about what does an application security program look like? What is its relationship with cloud security program? 


How do you even start building a cloud security program, and what kind of teams do you require for a cloud program? We also touched on whether to build a cloud program, should you focus on open source or should you just buy. As always, if you know someone who’s probably working on building a cloud security program or writing their cloud security strategy, or in general, maybe a CSOs trying to do a plan for what next year’s strategy may look like, this is probably the episode for you. 


Hope you enjoy this episode, and if you’re listening to Cloud Security podcast for the second, third, or four time, I really appreciate if you can subscribe onto our social media. We go live on YouTube and LinkedIn and on Twitter as well. So if you follow us there, feel free to drop us any questions that you have or any topics that you wanted to ask to talk about. 


And if you haven’t checked [00:01:00] out, definitely check out the recent video we did on YouTube on the CSP original. On Csbm C, WPP, and CNA and C, Im basically the four Cs from Gartner that no one cares about. Hope you enjoy that video. I’ll leave a link for that in insurance as well. And also, this is the last episode for Modern Security Stock month that we’re running next month. 


We start with Security Month in celebration Ofan North to America. That’s gonna happen next month as well. So I will talk to you on a new episode theme next month, and I’ll talk to you. J. Peace. So welcome, welcome, Travis. How are you man? Howdy. Good to see you. Good to see you as well. So maybe a good place to start could be for the one or two people who don’t know who Travis is on the internet. 


How would you describe yourself and your journey so far? 


Travis McPeak: I’m a security generalist, so I’ve love security ever since I was a kid and generally have worked in security at big companies. So when you, when you do things at big companies, there’s a lot of requirements that. But have recently become quite interested in startups and started a startup of my own. 


So started at big companies and working my way down, starting at 


Ashish Rajan: a big company and working your way down as well. That’s pretty cool [00:02:00] man. And this is probably exactly the thing that we need from a application security as well, Clark program as well. Cause a lot of people maybe are different parts of, or different phases of their journey as well. 


And to start off with, what is a application security program? What is a cloud security application program, Travis, to start off with so we can level the playing field for everyone who’s listening. Sure. 


Travis McPeak: Yeah. So we have different levels of the stack that we’re responsible in security. There’s the application, the thing that you’re developing if you’re at a software company and you have to secure that. 


And there’s all kinds of fun application vulnerabilities that come into play. And then at a separate layer, if you’re running in the cloud, then now you have cloud security and fun vulnerabilities that come into play for that. So in both cases, you’re dealing with, reducing risk, handling vulnerabilities hopefully proactively solving vulnerabilities, but different layers that you operate at. 


Ashish Rajan: Sweet. And to your point then, if it’s about eradicating vulnerability at different levels, What’s a traditional application security program look like? 


Travis McPeak: It depends on when we’re talking about and where, but traditional application security, there’s usually some kind of risk [00:03:00] assessment. 


So you hope to understand the way that your application stack works. Who’s creating that, what they’re creating, what components fit together. Typically come up with some kind of a paved road like way of doing things. So there’s all kinds of vulnerabilities that it’s possible to mitigate if you have the right components in place. 


So application security teams might build that. Definitely inventory. So in security, we all know that inventory is the root of everything, so you definitely need some basic inventory and then a whole bunch of other, fun practices and tools come into play as well. 


Ashish Rajan: You mentioned Paved Road. 


What’s a Paved Road? I mean, , you and I understand it, but a lot of people would not even know what Paved Road is. 


Travis McPeak: So Pav Road is is the nice way of doing things. So if you go on the paved road, all kinds of goodies accumulate, you don’t have to worry about too much, you get nice tools and things around it. 


So the idea is that you have this carrot that you lure developers or users to follow the paved road, and then they don’t have to worry about very many things. 


Ashish Rajan: And would you say do guardrails play a role in this as well? On the Paved Road? 


Travis McPeak: Of course. So if you’re on the paved road and you’re just going down it, then security should come for free. 


You shouldn’t have to worry about too much of it. Guardrails is really, the way I [00:04:00] describe it, is about, you know, preventing people from going off the road or from doing dangerous things. So the same way that you’re driving on a mountain road. There’s this nice retaining wall or, or rail or whatever that stops you from driving off the cliff. 


That’s what we all also wanna do for developers and users to help them prevent from doing something bad or dangerous. 


Ashish Rajan: That’s perfectly well put as well. We’ve spoken about what a traditional application security program looks like. 


Now you’ve been at Netflix as well scaling this to kind of like a cloud first cloud ready kind of program. A lot of people may be starting today in a cloud first company maybe or cloud ready company, however you gonna describe it. What does a cloud first company look like? Maybe to start off with, for people who. 


Know what that term means. . 


Travis McPeak: So cloud first, you know, means born in the cloud means that you can use cloud tools and bake in cloud to your processes. So you don’t have to, for example procure services, you just get them click a button and it’s up and running. And because of that, now a whole bunch of problems are handled for you. 


You don’t have to, for example, do an inventory of what servers [00:05:00] you have. There’s the cloud provider knows what those are, they can give you a list, but it also introduces all kinds of other challenges they come into. 


Ashish Rajan: Right. And talking about challenges as well. What does a program for apps that look like in like a cloud ready, born, the cloud kind of world? . 


Travis McPeak: So first of all, I’ll say that this is not a one size fits all thing. You know, Netflix, I learned a ton there. It’s a great program, but you know, Netflix is approaches and for everybody, so Netflix is not heavily regulated. There’s not all this compliance things that come into it. And the culture there was that we really wanna support developers and let them move quickly and innovate. 


And so developers are running as fast as they can. It’s security’s job to run along and help them. You know, like the, the people in a race that will run next to you and give you food and water, That’s what security does in a place like Netflix. So yeah. So basically what, what does it look like? 


It looks like so developers in a place like Netflix, we’re in a DevOps shop. So developers develop microservices and they’re fully responsible for those services. So ,in a traditional like kind of waterfall model, You have software engineers and then they kick over what they create to the qa, [00:06:00] and then they kick that over to release engineers and security and all these kind of things in a DevOps place, like the development team is doing all of that. 


So they fix it in the middle of the night when it’s broken, and they’re also responsible for security. Now, as you can imagine, security is quite complex topic and it’s not feasible to ask somebody that has all of these. To become an expert in something. And so what it looks like is the security team builds tools and practices and guidance and all kinds of stuff that makes the developers able to effectively own security for themselves without having to spend all of their time doing it. 


Ashish Rajan: Oh, right. And so if they’re able to just own it, does that help them scale or does just complicate? Cause I, a lot of people would imagine, Oh, what does security doing all this, the developers are taking care of. 


Travis McPeak: Totally. Yeah. So what security does is build the things that can developers can use to do it. 


So really like tools. I’ll give an example that’s not security. So in Netflix there was this great kind of central teams about reliability and what they would build is systems that help you collect metrics and then how to process [00:07:00] those metrics. Best practices around that. Like how do you actually use metrics? 


How do you get notified when something’s broken? So in the same way that that team did it for reliability, in security, we do the same things. We basically build these tools that developers can. That allow them to move quickly while also having security baked in. 


Ashish Rajan: Oh, right. So maybe let’s talk about some challenges as well what kind of challenges exist in like a microservices kind of world for traditional security teams? 


Cause sounds like you’re talking about coding, you’re talking about building tools, which is not a, Well, I don’t wanna ditch all the traditional security teams out there, but that’s how really traditional is. 


Travis McPeak: One thing that traditional security teams focus a lot is developer training, for example. 


So the idea is that if you teach folks about vulnerabilities, then they will write code that doesn’t have those vulnerabilities. So you’ll do like a, an all day class, and it’ll be like, here’s what command injection looks like, here’s how to prevent it. But the thing is, is that if if folks learn something and then they don’t actually practice it, they don. 


They don’t have it when they [00:08:00] need it. So it’s not enough time spending like to actually train folks that they tend to recognize these things or prevent it. So what we want to do instead and the approach that I’m talking about is build tools that if the developers use the tools, then they don’t even have to worry about what command injection looks like. 


It’s just simply like not possible to write it. 


Ashish Rajan: Oh, how do you do that? 


Travis McPeak: So let’s take a simple example. There’s like command injection and Python. And one of the common ways that this happens, there’s a, a subprocess call that you can make. And one thing that you, if you say like shell equals true, then basically takes all of the input and just dumps it into a shell. 


And so what you get here is shell injection. Somebody will basically, Escape the command that somebody was running, you know, like a semicolon. Now Linux thinks it’s a new command and then an attacker can write whatever they want. So that’s how command injection works in Python in one of the ways. And so what you can do is if you don’t call the function with this argument, Then it doesn’t work. 


So what you can do as a central team is basically you create a paved road, which is the way that people should be calling commands. [00:09:00] And you can build all kinds of cool stuff into that. So , you get like logging, so it’ll automatically log the commands that were run and other, other cool stuff like that. 


But because you control the function, you can also make it impossible. So it will actually, it will actually like escape all of the commands as they’re being run. And it’s not possible to do command injection. . 


Ashish Rajan: that’s so cool. And because it’s a library or function being created by the security team, so you can trust it as well. 


It’s not a third party, so I guess it’s maintenance and life cycle of that function that comes with it as well. 


Travis McPeak: Yeah, and I mean, in, in Python there’s like a built in way of doing this, so you don’t even have to necessarily create anything new. But what you can do is you can say, This is the way that we do. 


This is, the way that we write this at, at our company is we, we use this helper function. Mm-hmm. , and then you can use tools, you know, some graph or, or things like it to basically detect calls that aren’t following your convention. And you can just say, Hey, like we have this style guide. We should be using this function. 


You didn’t use it. You’re not saying there’s a vulnerability, but you’re just saying you didn’t use the, the way that we do things here and help developers. 


Ashish Rajan: Oh, okay. I, I love this and I think, I love the [00:10:00] way this is going as well, but I think a lot of people may be also confused why I started the conversation with, when I’m calling the, the thing as building cloud security program, and we’re talking about application security. 


A lot of people in the industry at the moment believe that, especially after the Amazon announcement at reinvent, where they’re asking people to have security champions program work with the developers a. Industry has already started noticing and started talking about the fact that the cloud security program, from what it used to be, the whole infrastructure security side and the application security side is kind of combining. 


So maybe to kind of level the plane field over there as well. And you kind of define what cloud program is earlier. Do you believe that these are kind of converging . 


Travis McPeak: I think in security you see a lot of kind of shared patterns. And so a lot of the same problems that exist in application security also exist in cloud security. 


Like inventory. You always need an inventory. You need to know what you’re working with. And that applies in any domain of security. You know, corporate security is the same thing. And then there’s like, Typical kinds of vulnerabilities that show up again and again. So like, you made something that has bad, [00:11:00] there’s, that exists in application security, that exists in cloud security, you know, least privilege in, in both domains. 


So the problems tend to be like the same kind of problem, but there’s so much domain experience required to set things up correctly that I believe that there’ll never fully converge. I think that there will always be room for cloud security to do cloud security things and application security to do application security things. 


Ashish Rajan: Right. And so what would a cloud security program look like , at a startup level, and maybe we can start maturing it to like a Netflix kind. So where does a cloud security program usually start? 


Travis McPeak: Sure. At the beginning of a startup, you don’t have a security person. 


Everybody’s kind of doing a little bit of everything. Hopefully you have a few people that think about security and can get some good practices set up. And I’ve actually seen companies you know, one of the things I like to do is work with startups and help them with security. I’ve seen companies get a long way with that. 


So, you know, for example one of the, the companies that I advised was a series C company, by the time they hired anybody for security, but they [00:12:00] had had so much good talent in engineering that was thinking about security, they were actually in really good shape. So at some point you hire a first security person. 


I’ve helped companies with a few of those as well. And you generally need like a, you know, this person’s gonna run around and do a lot of things, but the general shape of it for tech companies, It. I usually recommend a product security person, so somebody that really can understand your application and how it’s built, but also the infrastructure that runs on. 


And then in their spare time they can run around and like button up, you know, your corporate stuff as well. Then that person at some point gets to the level where they can’t scale anymore and they need to have some kind of a team around them, so they may become a manager. They may hire a manager, but in any case, you now have a team and at the team you know, once you’re two or three, then typically it’s somebody’s job to pay attention to cloud security a lot. 


And I mean, I would always recommend start with the basics. Like have a good inventory, have patterns that you don’t want to have used. Have some kind of a way, something like guard duty that will tell you when things are going off the rails. Try to, have a handle.[00:13:00] 


Buckets and being public and accidental data exposure, tagging becomes really important. So knowing what something is and like having a tag strategy that you can apply uniformly. And then of course just, setting up the basics. Like do you have logging in place? Do you have like an identity account maybe that then is federated so you can go and access other accounts. 


Do you have lease privilege? Like all of those kind of things would be, the typical first priorities for a cloud security. 


Ashish Rajan: I’m glad you didn’t mention a CSPM or one of those tools, in the first go. Cause a lot of people have that assumption that, Oh day one when I started, I need to do a csp m guard duty is pretty good. 


Security hub is pretty good as well. So you just wanna make cloud native tools. What are some of the challenges you see as someone who’s trying to build a cloud security program? Today’s day and age where most organizations, as you kind of scale the complexity or the scale of the footprint that you have of in your cloud environment is also quite large. 


So let’s take it up a notch. I’m no longer in a startup. I’m trying to get some money, get some customers, scale a [00:14:00] bit more. I’ve got hundreds of AWS accounts, or maybe even Azure subscription, maybe even multi-cloud. If I dare I can say that maybe a bit later, but how do you see is the mature from 


I’ve heard what Travis said, did the, the basics, right? I got guard duty, I’ve got cloud trail, I’ve got all these basic things running. , what are some of the challenges you see when people kind of scale to the next level of, you know, next big footprint of a medium size organization? 


Travis McPeak: So , you mentioned CSPM. 


I think that that’s important. Yeah. I’m kind of a way of detecting cloud security issues, but now that I talked to somebody today and they literally said, Okay, I have a CSPM and it detects zillions of issues. That’s like the exact term that you use. And, and that’s right. You know, like these things are so hard to get back in line. 


Like once you have this dashboard that’s telling you about zillions of issues, so Yeah. So then now you want to shift as far left as possible. It’s like some kind of a proactive. Where you’re creating cloud resources in a way that don’t have issues. So one thing that a lot of companies will do is, you know, for example, Terraform modules, like this is the, the blessed module to [00:15:00] use when you create like an S3 bucket or an RDS or whatever, and those things can have best practices baked into it. 


And the same way that I was talking about the function and application security, you can essentially create a resource function for your cloud and then get developers to use that. 


Ashish Rajan: Oh how would maybe, if you don’t mind, almost like double clicking under the resource function. So how would a resource function work in a Terraform kind of world where, so people are using terraform to do by infrastructure. 


They build that. And is there a custom model that security would develop for IaC checks 


Travis McPeak: Totally, so let’s say that you want an S3 bucket. Yeah. Because it’s easy. So what do you want from an S3 bucket? You want it to, you know, not be public unless there’s like a specific approval you want to have server side encryption on you want to configure it with logging, for example. 


So you would create an S3 module that developers should use that has those field. Internally it has those set. And so developers don’t even choose that. They just get those baked in. And then you could also do things like, you know, I mentioned how important it is to stay on top of tagging so that you know what [00:16:00] something is later. 


So you could have the tags like baked into it. Basically when you use the module, it parses out fields that you have and actually like applies those as tags. So those, those kinds of things, like you can be used to enforce conventions within a company. So it’s basically like creating a paved road for cloud resource. 


Ashish Rajan: All right. That’s interesting. So to your point then, if you have a resource model created as well, If I were to kind of draw the skeleton of a cloud security program sounds like I need the foundational pieces of having the inventory right and then a CSPM for ongoing posture management, for lack of better word, which to your point, may give you zills of alerts. 


Then there is a whole concept of how much can you shift left, which is part of the cloud skill program. You’re now basically building modules as well, and you’re using infrastructure as code. What are the components you see in a cloud security program that people may require? 


Travis McPeak: You know, at the end of the day for any cloud security program, you need the inventory, like you mentioned, you want to proactively reduce vulnerabilities. And then, [00:17:00] yeah, you know, I would say that this is maybe a, a subclass of vulnerability, but you know, least privilege is really hard in a cloud environment. 


You know, let’s say you have an application, it’s probably gonna be like relatively static. You know, you can set it up right the way that it, it works on disc. You can give it access to like certain file paths and you’re good to go. Or if it’s in container world, you give it certain capabilities and those aren’t likely to change very much because the nature of your application is relatively fixed. 


In cloud things tend to change more. So you know your application that’s running in the cloud, maybe it was using a database, now it needs access to something. And so actually, like coming up with least privileged strategy tends to be quite hard. So what we did in Netflix is we built something called Repo Kid. 


Repo Kid will use, basically observe an application running in the cloud or a user running in the cloud for some period of time, and then remove permissions from a default role that they don’t end up using. And so what you get is like, you start off with a little broad and then it converges down to at least privilege over time. 


But even then, permissions can change. So you need some kind of [00:18:00] a way where folks can get things back, you know, self-service or something like that. And you know, permissions are quite complex. So there’s, I don’t know, 200 AWS services and you know, 5,000 permissions or something like that. And they’re like sometimes named a little confusingly. 


So helping developers even to know what your requests becomes hard. So like that would be, you know, an extension of what the cloud security team might do is these like tools or guidance or practices around how folks actually operate their workloads with least privilege. 


Ashish Rajan: Wow. So very well put. 


Cause I think the self service is an interesting angle as well. We had someone from Twilio recently and they were talking about threat modeling as a self-service option. In an organization at at at scale. So do you see that least privilege of, Im in general for role changes or doing. Any kind of modification. 


The ultimate level of maturity for that is some form of self service. I’m gonna use the Netflix example, but maybe they do it or they don’t do it, but it’s an angle [00:19:00] where most, like, say 70 to 80% of the activity that a lot of people spend a lot of time in. For example, what you mentioned, changing my role, permission from where it has become to what it used to be or the other way around, that becomes a self-service function. 


So 70 to 80% of the, their role is more of, Hey, I made a tool, now people can do self-service. I focus on more specialized tools. Is that what you see as the I guess a mature state for a modern security, cloud security team? 


Travis McPeak: Yeah, absolutely. And the self-service part is really important. So developers are doing a lot of things. 


As a security team, you’re never gonna be able to scale with them. There’s just a lot more of them than there is of you, and you definitely don’t wanna be getting in their way. You want to help them to move as quickly as they want to move. You know, a, a bad pattern would be, Somebody wants something, they have to go to the security team and then you wait around for a couple of days because security’s busy. 


So that’s like that experience. People don’t like the security team when you do that kind of stuff. So what we wanna do instead is create these self-service ways of getting what they need. So for [00:20:00] example, in Netflix we had an S3 bucket creation Slack bot. If you wanted an S3 bucket, you would go into the Slack channel, run this bot command, and it would spit out your S3 bucket. 


And what’s cool about that is since we controlled the way that you actually use that, we could apply all this cool stuff on top of it. It was set up securely, it had tags, all of that kind of thing, like it was baked into it. 


Ashish Rajan: How do you get developers to actually use that bot in the first place? Is that, Cause you know, this is kind of where the culture conversation comes in as well. 


Like the whole people process technology part. We spoke about the the technology side as well, but there’s the whole people processing as well as worthwhile calling out here. How do you encourage developers to use that preferred slack port as a way. To create a to your point Paved road for Creating Cloud S3 buckets. 


Travis McPeak: Netflix, like, we definitely didn’t want to get in any anybody’s way, but we also prevented developers from doing actions that we considered risky. So without, without the Slack bot, then you have to come into the channel and ask us to make an S3 bucket for you. 


And we’re, we’re busy, like we [00:21:00] do our best, but we’ll get around to it when we get around to it. Yeah, so folks would actually prefer to use the Slack bot because it’s better than having to wait. 


Ashish Rajan: But okay, so they themselves would not have the permission to create an S3 bucket apart from just either a Slack bot or using some kind of a way to request, hey, security, we need S3 bucket 


created. 


Travis McPeak: That’s right. Yeah. And another example of this is IAM so, IAM, , you can do all kinds of stuff. We definitely don’t want to be giving developers like cart blo. I am. So Netflix has something called console me. It’s open source, but that’s the self-service way of requesting new permissions for your roles. 


And it had guardrails baked into as well. So you as a developer, you can go into the Slack channel and ask somebody to help you, or you can just use console me and get what you. 


Ashish Rajan: Right. You know that reminds me of one more thing. Where that happens quite often in the cloud security context also is a lot of times Amazon or Azure or whatever, they might release a new service, whatever, like AWS SageMaker, let you use that example. 


Cause that’s more, the most fresh one in my mind that came for approval and nine or 10 times [00:22:00] is because the use case that the team has identified, they only usage AWS SageMaker. And nine or 10 times, no one in his security team has an idea, Well, what the hell this subject, this service is? So they would just say, it’s like a blanket rule. 


I’m just gonna. Review this fully. And again, there are holes in that fact of, you know, doing a blanket approval of SageMaker or any of the new service that you add because they might, you know, Amazon would choose to add more features, which are more un insecure. But where do you stand on that? Like whenever a new service comes out, how does a modern cloud security program kind of usually work with these kind of scenarios? 


Travis McPeak: Yeah, so one of the least favorite times of the year in cloud. Was reinvent time. Cause reinvent was like release, you have 50 new services or whatever. And then there’s a bunch of developers that want to use it. And ideally, like we can actually look at these things and see like, okay, is it risky? 


Like where are the sharp edges? And kind of like file the sharp edges off and then let developers use it. But again, we don’t wanna get in anybody’s way, so, One pattern is you can basically just make it [00:23:00] easy in self-service for folks to spin up environments. So you know, self-service, create your own account. 


It’s got some kind of like a service control policy on it or something. So you can’t do anything like wild in there. But other than that, like, go ahead and create your resources and just give developers guidance that if it’s for production, that we want to like take a look at it before you do anything. 


Ashish Rajan: All right. So they could create an AWS account with just use SageMaker as an example. So they could create a new account with SageMaker, but that would not have access to anything production. It would just be isolated account. 


Travis McPeak: That’s right. Yep. In its own little sandbox. And then within , your toy account. 


We give you, permission to do basically anything. So you can spin up your own SageMaker, you can add SageMaker, but we’d file off the sharp edges. So you can’t like create new IAM roles you can’t screw with cloud trails, stuff like that. Right. 


Ashish Rajan: So I mean, cuz I think I’ve seen this in the past and what, what tends to happen , is always someone trying to create an exception as well. 


Have you, in your experience, come across exceptions for these kind of scenarios as well and how did you end up handling them as part of the cloud security program 


Travis McPeak: [00:24:00] I think the only constant is that you’re gonna have exceptions. So I actually like really encourage any security team as they’re rolling out anything to think. 


What is the process that somebody goes through if they need to get around this policy? And like, what kind of policy exemptions would you consider? But yeah, like communicating that in advance. So for example, you know, repo kit, I’ll use that. The thing that would remove permissions in AWS environments because I’m very familiar with it. 


We, by default, we would apply this to all. But we did allow people to opt out because we really wanted developers to feel bought into this thing. And if you don’t want us to, to help you get least privileged, that’s fine. You can opt out. You know, some roles you know, I mentioned that what we would do is like look at usage pattern and remove on used permissions. 


But some roles like you by necessity, like have permissions that you only need to use infrequently, but you really need them. So like, The incident response team’s role, like, you know, that hopefully they’re not having incidents all the time, but when they’re, when they’re having an incident, they really need those permissions to work. 


So that would be like a typical exception around the way that we did least privilege.[00:25:00] 


Ashish Rajan: Wait, what, what about scenarios where developers want access to data because, hey, we’ve done all the testing, we know exactly what you wanna do, but we now we want to test with data. 


We’ll use this test data. Don’t worry, we’ll just use test data. So how does that kind of experience shaped your thinking? 


Travis McPeak: I’ve seen that, I’ve seen, you know, oh, we’ll just, we’ll use test data, but then they actually want access to, to prod or like, you know, I want, I want read access from tests, like against prod data or like, I wanna copy the prod data because like, you know, my exceptions only like this error that, I’m trying to debug. 


Only happens on this pro data for whatever reason, . So yeah, I mean, there’s all, there’s all kinds of stuff like that. If it comes up a lot, you know, then we’ll try to create like, some kind of tooling or process around it. You know, there’s a, there’s a company that I looked at called Tonic. I don’t, I’m not like affiliated with them in any way, but they’ll generate like, test data for you that looks good. 


So like those kinds of things. You know, that, that can be useful. But yeah, I mean, the only constant, like I said, is that you’re gonna have some kind of exception. And generally our goal is to support developers wherever they, they need to be. So, We don’t want to be like, [00:26:00] if they feel like they need to test on this data, it, it’s our job to figure out how to do that safely. 


It could be like kind of creating a little sandbox environment where they get like , some kind of a role to access across account, but it’s scoped down and they can only do it within the confines of like a VM that’s like super locked down or something like that. You know, there’s always like ways that you can kind of draw boundary around it. 


Ashish Rajan: Right. And thank you for answering that as well. Cause that’s probably one of the, well it is a bane of few, few security folks life. Cause these scenarios that I came come up with having faced some of those and having had conversations of how people have had difficult conversations around this is definitely worthwhile sharing as well. 


We’ve defined what the skeleton pieces of a Cloud Security program i’ve thrown a few curve balls as well. One curve ball that I had not thrown at you so far was the compliance piece where the whole compliance in cloud, like every, every program, even as a CSO that are designed. 


The strategy for security program, usually for the POS next couple of years, compliance plays a huge role. Like it’s probably not spoken right enough. How do you see compliance? Function in a [00:27:00] modern, scalable company like, you know, cloud first, cloud ready com, born in the cloud company. How does compliance play a role in those kind of things? 


Is just basically isolate and move on or what, what’s the strategy there for for those, For those programs? 


Travis McPeak: Yeah. I mean it really depends on, you know, on what the compliance thing is. I’m actually. You know, I’m not a giant like compliance fan by any means, but I’ve actually been a little disappointed about how little compliance is actually applying to most cloud environments. 


Like they, they haven’t reconsidered the impact that Cloud has on the standard itself. And there’s, you know, with a few exceptions, like FedRAMP, there’s actually not that much specific guidance about how you should do. Cloud with compliance. You know, that said like, yeah, there’s like the usual tricks come into play, so, oh, like, you know, this is the PCI environment over here in the corner and we have to do all the PCI stuff in that environment, but you make that as small as possible. 


Ashish Rajan: And wait, so, cause that’s a good example as well, cuz I think most of us just resorted that it was just the easiest way to do this without again, becoming a blocker. So maybe taking a step back then, [00:28:00] we’ve kind of spoken about what does it look like as it, as it move forward. For people who are probably listening into this live stream and maybe later on to the podcast as well, what do you feel is a good starting point for people who are listening to you going, going, Oh yeah, okay. 


At least all these scenarios make sense. I should definitely start working on my cloud skill program. Keeping in mind it’s not gonna take happen in a couple of weeks or maybe take a few months or years as well. What, what’s, what’s your thinking around building a cloud security program when you kind of, So before our asset management just knowing of your inventory, outside of all of those things, is there a strategic play? 


That you normally recommend leaders to kind of think about when they are building cloud security program, especially nowadays compared to where it used to be where, I mean, regular breach was more like, Oh, another misconfigured server. Now it’s more like, oh, there’s an Uber breach and while the person had access to AWS and Google Cloud as well, like it was very indirect these days. 


So has your thinking around cloud, security programs, defining it and what they should look like, or [00:29:00] even the timeline for. I know it’s a very loaded question, but yeah. Hopefully I’m made through. Yeah, totally makes sense. 


Travis McPeak: Yeah, a hundred percent. Yeah, so I think the types of, of compromise you get and like what the actual attacker steps are, change a lot in a cloud environment. 


So, you know, traditional, you have an application security vulnerability, like somebody compromises your web application. Now they might get like some kind of a secret or something to a database. But here now an attacker has this extra step. They’re on a machine that’s running in the cloud, and that has a role in addition to like the secrets and other things that it may have access to. 


And so, you know, the, the least privilege here becomes really important. So you may have this like relatively low value microservice that’s compromised, but if an attacker is able to use that role, or use the network access to something else that’s in the same account and move over to that, that’s pretty impactful. 


So yeah, That’s like one of the things that you have to be be aware of. I would say, in terms of if you’re a new security leader and you wanna assess how you’re doing for cloud security take one of the the NIST type [00:30:00] assessments or whatever. 


Ashish Rajan: Or, CIS benchmark or something. 


Travis McPeak: Yeah. CIS benchmark. Yeah. Run in one of those and see where you stand. Just like you have the basics locked down. Like do you have root account, like basically, you know, mandatory hardware, second factor and locked and people aren’t using it. What’s the role set up? How do users actually get in there? 


What’s the least privileged look like of those roles? Are you using like VPC and segment segmentation like that? You know, if you have a CS P, like what do the issues look like? You know, basically like you just kind of wild west and people make whatever, like storage they want, or do you have some kind of like system around that? 


So I think those are kind of the starting points. It’s just nowhere you stand and then from there you can prioritize. I’m sure there’ll be like plenty of fun work to do. 


Ashish Rajan: What kind of team do you see being used for a cloud security program? 


Travis McPeak: Yeah. So this really depends on the organization At Netflix, one of the things that we did the most you know, we believed that good security teams will build tools that make developers’ lives easier and have security baked in. 


So we actually hired a lot of builders. On the cloud security team, every person that was on that team wrote [00:31:00] software. And it’s not like we just wanted to. Tools like for the joy of creating tools like Netflix created Lemur and Security Monkey and Repo Kid and console me. And like all of these basically open source things because there was no product at the time. 


Like we knew that this was important, but there was no commercial product that solved these needs. Now, Security Monkey, for example, today. There’s a whole bunch of CSPMs, but Security Monkey was like really one of the first ones. So we had to make it. Yeah, yeah. We had to create this like inventory CSPM type thing. 


So you know, assuming that you have the basics in place and assuming that you’ve been able to buy tools that do all of the usual kind of stuff, there’s going to be specific problems to your organization and being able to like cross functionally work with developers, you know, communicate well but also build at least lightweight tooling becomes quite. 


Ashish Rajan: Right. And so to your point, team of builders, would you say taking a bit bit more kind of CISO kind of, or maybe even a VP of security kind of cloud security kind of role as well? You have cloud security [00:32:00] teams, which are build off builders or cloud security builders, who can write code & tools red team. 


Those kind of things play a role in a cloud security program as well, or they’re more like they continue to do what they were doing. It just basically added function of cloud security in. 


Travis McPeak: So I don’t know, maybe I have like a controversial opinion about Red team, but my perspective is that Red team generally shouldn’t be finding problems that you’re not aware of already. 


And if I’m aware of the problem, then I don’t need a red team to go and prove that it can be exploited. Like I know it can be exploited for sure. I can like see it in my head. So it’s like kind of proving the thing that I already know. I think if you’re like a really well run place and you have all of the basics buttoned up and you’re like, great. 


Like we actually think we have no attack surface. What’s the low hanging fruit that a red team can be useful, but yeah, I mean, we would periodically get them at Netflix and they went after the things that you would think they would go. . 


Ashish Rajan: You know another thing that I wanted to call out is also a lot of the industry in cloud security at the moment with the CSPM, CNAPP and CWPP they are all about identifying your [00:33:00] current threat at the moment. 


And cloud security programs is all about. Hey, how do we build this thing for the long run? Yes, I need, I need to be aware of threats. Yes, I need to be aware of, I may get hacked tomorrow. They might be Uber breach or whatever. And sorry for using the Uber example, I’m, I’m sure that there’s no, no, no hate against them. 


It’s a pretty hard weekend for a, a few weeks for them and a few other people who have had breaches, so, I guess, where do you learn about building a cloud security program? Cause it’s almost like most of the information you find on cloud security is primarily around, oh, there’s a threat or to what, to your point, zillions of alert by CSPM, whereas I don’t see much coming out for, Hey, this is how you build a paved road kind of a thing. 


So where, where do people learn about these things? . 


Travis McPeak: I was lucky that I worked at Netflix and I learned a ton from just awesome colleagues around. And then I would say also, you know, talk to your peers in other organizations you know, , the wisdom of your collective crowd is really good. 


So you, I’ve definitely had some meetups where I would meet with, you know, people doing cloud security at other [00:34:00] companies, and they would, they would’ve like, tried out some idea. Sometimes the idea worked and sometimes it didn’t. But either way, I learned something, you know, they, they learn something, they can pass it on. 


So that kind of sharing is really good. I think there’s, you know, there’s now some conferences where people are sharing, you know, more cloud security. You know, in a pretty well focused way. So yeah, just, you know, learn from everyone else and then try stuff. 


Yeah. For, for Clouds is probably a good, great conference as well around my community and stuff as well for people who may not learn about it and check out their YouTube channel as. 


Ashish Rajan: Totally, a hundred percent. so Byron’s question is, should building a CloudGate program include open source? 


Travis McPeak: Yeah, so this is not, although it seems like kind of simple, this is not like a universal yes no thing. There’s pros and cons. So open source tools, like, you know, it depends on the level of support. You still need to understand how those things run and operate them whereas, you know, like a vendor. 


Like, yes, you’re paying for it. There’s less lock in factor, but the vendor may be very motivated to support you. So if you need a new feature request an open source. Nobody’s getting paid to do it. You have to wait for the community to pick it up, whereas a vendor might do it. So, yeah, it really just depends on like what the [00:35:00] factors are. 


Are you concerned about lock in? How much time are you willing to spend in it? Almost all open source like requires some kind of an investment on your part, at least to understand how it works and then, you know, maintain it and deploy it and all that kind of stuff. 


Ashish Rajan: I think the other side is also the fact that if you hire someone who’s great at building a tool and maintaining a tool, maybe deploying and implementing an open source tool as well, what happens if they leave as well? 


It’s like, do you have right skill within the team to carry on the baton, after they leave? But yeah, that’s another one. Great answer as well. Trying. Thank you for the question as well. Byron. Great question, man. Sweet. 


That’s kind of what the technical questions that I had. Now, it’s kinda like the fun section for me now where I’ve got three questions, just so not technical, but more about the kind of, just for people know who Travis is . 


Fun question. So the first one, where do you spend most time on money? Not working on cloud or technology. 


Travis McPeak: I have a family. I’ve got kids. They, they keep me on my toes. There’s always always something new and fresh with them. It’s really cool to watch them grow. 


But aside from that I really love mountain biking. I pick this up during covid. It’s a way to get thrill [00:36:00] and some good exercise and hang with friends. And also, as you know, we’re, we geek out on the weight lifting stuff. So I do that every morning. It makes me feel awesome. And then you know, it’s like something that my quantitative brain likes. 


I can see progress over time. 


Ashish Rajan: That is pretty cool. I think people should follow us on the Twitter handle list, on the screen as well. So just to know the kind of body hack conversations we have. I guess the next question, what is something that you’re proud of but is not on your social media? 


Travis McPeak: I guess it’s on my social media a little bit, but I’ve really been enjoying working with other startups in in angel investing. So basically becoming involved in other people’s companies and helping them, I think, I don’t know. Yeah, the startup stuff really just has my mind right now. 


And so anytime I can pass on something that’s useful for somebody that’s creating a company, which is quite hard I really enjoy that. So I, I’ve talked a little bit about it on social. You know, kids, I don’t mention them too much, but yeah, the kids are, are fun and doing cool stuff. , 


Ashish Rajan: that was pretty awesome. 


Kids are always doing cool stuff, man. I think I’m some, some of envious of the opportunity that I see them create, but I think it’s definitely very proud [00:37:00] moment is to see kids excel. 


Travis McPeak: We were, we were jogging around the other day and my, my we went to Hawaii like a month ago. And my son, you know, he is four, he like pointed to this car and he is like, that’s like the car that we were in in Hawaii. 


And he was like, Totally right. It was like the exact model and color and everything. It’s like, how did you know that man? 


Ashish Rajan: Oh my God. Yeah. There you go, man. I got one more question for the fun section. 


Travis McPeak: What’s your favorite cuisine or restaurant that you can. 


Ooh. So my wife and I celebrated our eighth Ann. On Saturday, and we ate atan in San Francisco. Thank you. That, you know, it’s like high end. We’re, we’re not rich people by any means, but we ate some really fancy food. So I like that stuff. Just where, you know, like the chefs just show off, just pure technique, you know, they create something that’s just so flavorful and just looks beautiful. 


So I like that kind of stuff. But yeah, on a regular basis I love steak. I love like a really good steak. I love Mexican food. I kind of love all food actually. 


Ashish Rajan: Nice. Well that’s where hashtag Gaines man hashtag gain all the meat. Yeah, exactly. All the meat. Cool man. That’s, that’s kind of where [00:38:00] I guess cause the questions, the time that I had with everyone. 


Where can people find you and kinda tell us about , what you’re working on these days as. 


Travis McPeak: Sure. Yep. So find me at Travis McPeak on Twitter. Travis McPeak on LinkedIn. So I started a company six months ago. What we are doing is building a way that makes it easy for developers to create and manage cloud resources. 


So basically like a productized paved road for people that want cloud stuff. You know, we think developers have it hard, we wanna help them. So we’re building that you know, quite early company. So I’m kind of running around doing everything. I’m the finance person, I’m the marketing person. 


I’m, you know, interim head of hr, all kind of stuff. So, yeah, it’s fun. I like it. 


Ashish Rajan: Very awesome. And so I’ll lead the social on the show so we can follow to as well then. But dude, thanks so much for this. I really enjoyed our conversation on building a cloud security program and what are some of the challenges on it. 


Thank you everyone who joined in as well. All the a hundred plus people, Joe logged in as well. Thank you. If you have any follow up questions, feel for Dodo as a comment if you want to do play. Otherwise we’ll see you on the next episode, which is gonna be the next [00:39:00] month episode for Ommunity Security. 


We’ll talk to you next month. Talk to you soon. Thanks everyone. Thanks Travis.

‍