Ashish Rajan: [00:00:00] Are you a small to medium sized business or a startup with probably no cloud security team, or probably you have a cloud security team and you're working on a cloud security program, but technically your cloud security team is the DevOps team or the platform team as well. So this conversation with Chris Farris, who is a very well known person in the cloud security space, and who also is a AWS hero for security.

One of the first ones, which is a new category that was announced by Amazon. We had a chat with Chris at AWS re:Invent where we spoke about things like if you are a startup or a small to medium sized business today, what would that roadmap look like for you moving forward? What would that mean from a cloud security program that you may be trying to build?

What would that look like from a skill set that you want to have in your organization? If you are a startup today on day zero, what are some of the low hanging fruits, like the top three things you could do? By the way, if you're thinking CloudTrail, I would reconsider. Because if you have been in the space for some time, you probably know the advice that used to work really well for cloud security goodness in AWS [00:01:00] back 10 years ago is not the same today.

There's a lot more to it. And if you know someone who's a startup or a small to medium sized business trying to work on solving the cloud security challenge, but may not have a lot of resources like the large enterprises trying to figure out what that looks like. Chris Farris is looking to help people like yourselves through the AWS Hero program.

So that he can maybe share some of that voice and concerns to AWS as well. The same way we would like to help and hear voices from you on how you see the challenges of security as a small scale business in the cloud of AWS, Azure, Google Cloud as well. So if you are someone who's probably trying to solve this problem, definitely check out this episode with Chris Farris.

If you want to talk to someone about, hey, what are some of the things I could be doing as a startup or a small to medium sized business. Which is large enough presence in AWS that it is becoming a concern or even Azure, Google Cloud, definitely reach out to us and we'll be more than happy to have a conversation.

Also reach out to Chris Farris, who's the AWS hero, to talk about specifically what you want to share from an AWS perspective as [00:02:00] well. So he can pass that message to the AWS program managers as well. I hope you enjoyed this episode. As always, I appreciate all the love you share with us on social media.

And to subscribe and follow you give us on Apple podcast, Spotify, YouTube, leave us a review. All that helps us get in front of more people, helps us keep bringing more people like Chris Farris and others who are doing a great job with others in the fwd:cloudsec space. Also the cloud security community that we're trying to grow that is definitely growing.

I think if you did hear the stats from AWS re:Invent, they are trying to educate 25 million people on the AWS cloud. That means 25 million more people who have to be educated on the cloud security space as well. So if you are someone who's looking to. get more information about cloud security. Definitely let us know and please do share this episode with other people who are in that initial phase of their cloud journey as a startup or a small to medium sized business.

I hope you enjoyed this episode with Chris and I will see you in the next one. So welcome to another episode of Cloud Security Podcast. Today we're talking with Chris. Chris, for people [00:03:00] who may not know who you are, could you share a bit about yourself, your background, how you got into cloud security?

Chris Farris: Sure. I like to call myself an annoying cloud security nerd. And I've been doing AWS stuff since about 2014. I helped CNN with its broadcast migration to the cloud. And that gave me an opportunity to pivot into doing security for Turner. And then as mergers and acquisitions and other things happened, I got to take the program I built, expand it, re implement it at other companies, and things along that line.

I'm the Event Chair for the fwd:cloudsec conference. It started as the concept of what can we do in a conference that Amazon isn't letting us do at re:Inforce. What are the things that Amazon PR and marketing don't want to hear? Or don't want to put on their stage. And so we became a Bsides to re:Inforce and now we've moved off onto our own to the extent that now I think re:Inforce might be following us around.

Ashish Rajan: Definitely may look like there's definitely a need for [00:04:00] something like. open dialogue about cloud security between all cloud providers and not just one. So I definitely encourage that as well.

Chris Farris: Yeah. fwd:cloudsec is a multi cloud security conference. It's not just there's one cloud and then we don't talk about the others. We will talk about all of them and we will say the things that maybe they're a little bit not happy to hear said about them.

Ashish Rajan: Fair enough. And you are an AWS hero as well for security.

Chris Farris: I am one of the first AWS security heroes. They just created that hero category. You're a member of the community builders program. And so that's a nice opportunity to have an interaction with AWS. What's amazing about the heroes program is the level of interaction that AWS has with the heroes in general, right?

Service teams seek us out, one of Amazon's leadership principles, right? Is customer obsession. I believe that they look at the heroes as that voice of the customer, right? So in a way, there's a hero, a silly dorky term that, makes me think I should be wearing tights and a [00:05:00] cape

But really there is a responsibility upon us to really represent what the customers need. And I'm really glad that they've created this security category in the Heroes program. There have been a lot of us in the fwd:cloudsec community who were already heroes, and the cloud security community who were already heroes, but now they've officially created this category.

Ashish Rajan: And I think maybe a good point to start about. this conversation because you've done some time in the cloud security program space as well building, a lot of people who listen to the podcast are leaders and VPs, Directors. CISOs as well looking to build the cloud security program. Now we are already at the tail end of 2023 and 2024 is coming up as well for people who are trying to think about cloud security programs building them.

I've normally put them in categories of people who have not done anything in that space to all the way to people who are like the Netflix of the world for that first category where people may be a bit lost in terms of where do I start with cloud security program. What's your recommendation? [00:06:00] Having done this in the media space, what's your normal recommendation for this?

And maybe also the nuance of what it's like in the media space as well.

Chris Farris: So I think there's two ways to look at it. One, you're just starting your cloud journey. And you have that greenfield opportunity to do things. I've never had that greenfield opportunity to do things. And I'm not sure, honestly, unless you just signed your incorporation paperwork, you're not in a greenfield scenario.

But, you've got legacy technical debt, and maybe you've been in the cloud for many years. Advice on how to do things in the cloud has evolved. And what was best practice in 2010, 2012, 2014, 2023 is different. So you now have to evolve and you have to go back and figure out, as Werner said this morning in the keynote, you have that level of technical debt and every day that you're holding that debt, you're paying some form of interest on [00:07:00] it.

Now, in the case of security, that technical debt interest is more risk of security incident or breach or whatever. So for companies that are just getting started, stick to a single cloud, build an expert in your organization on that single cloud, and work with your building community, your developers, your DevOps engineers and everything else, to get everything in at the front end.

Don't just say, okay, we're going to go and we're going to implement a cloud security posture monitoring system. And that's our cloud security. Because if you look at the shift left spectrum. Cloud security posture monitoring is all the way on the right, and that's the last thing that you want.

It's flinging spreadsheets at developers for issues that are over a week old. Implement in your pipelines, implement in your architectural principles, implement in your Terraform modules or whatever, all the best [00:08:00] practices that you want.

Ashish Rajan: So now that we spoke about the people who are starting today.

And you graduate a bit more to people because I put that first category of people who probably had on premise debt and as well as people who are trying starting today agile world or whatever. Now, what is day 0? Once you pass the day 0 part, what do they need to think about from a day one perspective for cloud security programs?

Chris Farris: I still think it goes back to educating and empowering your developers and your builders. Let them know that access keys are the primary way that a cloud security incident starts. And if you're a leader giving them the time and space to invest in building the capability of here's how we will vault and manage secrets collectively rather than every engineer, every builder having to go figure out how they were going to implement secrets management themselves. So layer on [00:09:00] these capabilities. Here is the foundational network that we will build that everybody can operate in. Here is the foundational IAM strategy that everybody can build in. Take that time and investment. And I realize that a lot of startups, especially if you know your day zero, it's We have to get product to market quickly, so you have to know that this tech debt is something that's critical.

At some point, you will have to redeploy. I think one of the earlier things I learned about software development was, throw the first one away. You're going to go, and you're going to open an AWS account, and you're going to start building. And then suddenly you're going to go to AWS and say, I need an enterprise discount program, and they're going to go apply it to your production workload account, and then you're going to hire a cloud security person, and they're going to be like, Oh, because they can't now implement AWS organizations correctly because the enterprise discount is on the workload account, not on the [00:10:00] new organizational management accounts.

And so suddenly now it's okay, AWS legal, your legal, trying to renegotiate something just to implement a little bit of basic security. So there's, and I want to do another podcast on this around top five things that a founder should do on a Saturday afternoon that will take them about three hours that will save them weeks and weeks of work, six months to a year from now.

Ashish Rajan: Can't wait. And to your point then to adding another layer to this as well. As people are working on say, because the case that you mentioned is very much of a conversation that happens quite often, where a startup starts today, gone into AWS fully loaded and oh, we're ready. Now they've grown to become OpenAI or whatever example you want to use.

Suddenly that if you think about. That probably is a very home hitting example for a lot of people where OpenAI was like a November 2022 but it's so big. Yep. So I imagine there's a lot of people who want to be prepared for it, want to be ready for it. To what you said about [00:11:00] having the security done in the beginning, that not having any debt in the beginning.

Are there any low hanging fruits that they can add in their cloud security program? That maybe it doesn't have to be an entire exhaustive list, but even if it's top three that you can recommend,

Chris Farris: I would say the top one is enable AWS organizations and then put your workloads underneath that and enabling AWS organizations and creating a second account, super simple, if you're in Google, you can just use plus aliasing to create the new root email address.

And so now you've got the organizational account and you've got your workload account. Yeah. And you can apply security controls in one environment that will apply to your workload account and then everything else builds from that. The second piece is I would say implement AWS Identity Center because after it's no longer you as the founder and you hire your first and your second and your third developers, you don't want to be using IAM users.

You want to be using something like Identity Center, temporary credentials. Never putting an A. K. I. [00:12:00] A. The long term access keys in code or anything else. So really the two top things are Organizations Identity Centre the third one I would say is CloudTrail, but really CloudTrail is going to help you if there's an incident, but you don't want the incident that you know, and then maybe delete default VPCs and never exposed 22 to the world.

Things along those lines would be the kind of fast follows, but those are the obvious ones that, any kind of general, trusted advisor or cloud security posture monitoring tool will give you.

Ashish Rajan: I love that it goes back to what you were saying in the beginning, because the advice back in 2012 or 2013 used to be first thing we would say is log in with your root, enable CloudTrail, create IAM user.

That used to be the trajectory of recommendation for most people, but now it's more around. Make sure you have an organization created. It doesn't have to be like the, because you can move around the organization unit and do a lot more flexibility around it, but at least have an organization. Make sure you have an account underneath it, and then [00:13:00] not start with IAM user, but start with Identity Centre

Chris Farris: and you can enable Identity Center after turning on the AWS organization as the root user. I'm working on my alternative to ControlTower and, as I was testing it out for the first time, it was like, wait, I don't even need to actually create an IAM user. I can go directly from root after I entered my credit card and selected my support plan to enable organizations, enable identity center, log out, log back in as myself using my identity center ID, and then I can terraform, roll out my organizational structure and everything else.

Ashish Rajan: And for context, maybe for people who may not know what either Control Tower is or what Identity Center is, what is Identity Centre for people to know what that is?

Chris Farris: So Identity Centre is basically AWS. It used to be called single sign on. So if you've heard of AWS SSO, They've now renamed it to AWS Identity Centre it is a multi accounts way for humans to access both the [00:14:00] AWS console and the AWS CLI and APIs without actually having to generate single account bespoke IAM users.

AWS Control Tower was Amazon's solution. I think really for very big customers who are like we'd like to use your product, but we have all these reasons why we don't want to use it and we can't control what our developers do. And we don't trust our development community. So give us this rigid, straight jacket of your best practices.

And it was probably designed for financial heavily regulated businesses, but then it became an Amazon SA's answer to, Oh, Hey, I just got started. How do I set up account vending machine? And so now the recommendation from Amazon is almost the, we'll go put on this straight jacket and you'll have all these best practices.

And in my [00:15:00] opinion, that's probably not the right solution for a startup. I'm trying to work with again, leveraging, being a hero and everything else. Work with AWS to make things like control tower or landing zones or whatever else. Easier for the small company that isn't. A major bank or a government institution, or, somebody who has a stack of regulations this tall that they have to, adhere to.

Ashish Rajan: Yeah. And maybe that can come in a bit later because you can still have those policies implemented. You don't have to use Control Tower to implement policies.

Chris Farris: You don't have to use Control Tower and in fact, what I tell anybody who wants to get into cloud security is go build yourself a pet Control Tower

go down to the show floor at re:Invent, get yourself one of the little 25, get started in AWS credits. And that will run your pet Control Tower for a year. And you'll get to observe all of AWS's best practices, all the service control policies. How do I disable regions in Singapore [00:16:00] or Sydney that I might not want my developers building in?

Because maybe I have a GDPR need and I have to make sure that my data residency Is always in the EU. So turn off the United States, turn off APAC, turn off South America kind of thing. You can learn the ways to do it by having a pet Control Tower without finding yourself in a position where you foot gun yourself with Control Tower when you want to do something different or because you've adjusted it and Control Tower's like, Oh no, that's not how I like to do things.

Ashish Rajan: Are the policies available for people to to look at and see which ones, like I know Control Tower has a policy that are managed by Amazon. Are they exposed somehow to people through a GitHub repository or something?

Chris Farris: Honestly, I don't know. That's why I keep a pet control tower.

Okay. Cause because then I can, because Control Tower under the hood is nothing but AWS organizations, CloudFormation, stack sets. Part of the organizations is service control policies [00:17:00] and then a lot of service catalog. stuff for vending accounts and everything else. And I think where I find Control Tower is very limiting is you need a PhD in CloudFormation, custom resources and service catalog to be able to customize it in any way, shape or form.

Ashish Rajan: All right. And I think because the policy is still maintained by Amazon, it becomes even more trickier because unless you hit the wall, you don't even know the wall exists, kind of thing.

Chris Farris: It's in the name. It's Control Tower. It's controlling things. Oh, you want to do something, you want to take the red pill rather than the blue pill, you're going to have a bad time.

Because Control Tower is going to revert you back to what Amazon thinks you should be doing, not what you think you should be doing. And while I would say, listen to Amazon, they know better, sometimes, you actually know what you need better than they do. So I always keep my little pet Control Tower

yeah, I'll upgrade it and see what they're doing and I'll adopt their [00:18:00] practices. That makes sense for my organization.

Ashish Rajan: I'm going to talk about Identity Centre as well. Just to peel a layer more onto that as well. A lot of people from the start of make think, Oh, wait, single sign on. That means I need an identity provider, which could be their Gmail or Gsuite that they have as well.

But what do you see as common implementations of identity center for a Startup or that kind of level.

Chris Farris: So Identity Centre has come a long way since it was first released. I want to say I was probably having conversations in 2017, 2018 and it was like, Oh you have to create an active directory machine in your organizational management account.

And it was like, but wait, wasn't everybody saying, don't put workloads in your organization management account. So to use this, I have to do what you say I shouldn't do. Even to like a little over a year ago, there was no API to actually manage users and groups within Identity Centre so from the out of the box Identity Centre [00:19:00] gives you both a ability to authenticate and authorize IAM identities, but it also comes with a built in identity store.

So even if you're first setting up your AWS infrastructure before you've gone and set up your corporate Google or O365 setup, you don't need to, have an HR system. You don't need to have Active Directory. You don't need to have Google Workspace to use it. And you can programmatically manage users through their API.

Now. After you get to three, four, five users, you probably have an email thing. And on my blog, primeharbor. com, I've got two articles describing how easy it is to hook up Google Workspace with Identity Center or Azure AD with Identity Centre

Ashish Rajan: yeah, very straightforward. And I think there's a lot of documentation, so maybe the blog is a good reference as well.

So we spoke about cloud security programs for startups. We've also spoke about what's top two things or three things I can look at [00:20:00] as good practice to recommend as a starting today in terms of, scaling this out. I imagine there's a team conversation as well to be had. It's a people process technology , we've got the technology bit, but actually, maybe before we go into that, because I would say some of the experience you had from the media industry versus people who may be in a startup world, which would be.

Hey, I'm going to go into finance because bank has all the money in the world. I want to make a startup for a bank. What did you find as difference between, say, in the media industry versus a non media or regulated industry kind of a thing?

Chris Farris: So I think my experience in the media industry was one. I was in large media companies, so we had lots and lots of brands and all the brands had their own reasons why.

We must do things differently than the sister brand over here. Yeah, so it was lots of teams doing a lots of different things I'll be slightly politically incorrect here and say in security, sometimes diversity is a bad thing when it's diversity of technology stacks, right? It was very [00:21:00] hard for me to say, okay, this is how the company is doing things.

Let me target that. It's okay, this team is doing that. This team is doing that. This team is doing that. And I was operating, especially when I started as the only cloud security person, I had to settle for the lowest common denominator. So it was, okay, the lowest common denominator is ClickOps, we didn't have a company standard that we used CloudFormation or, Terraform, half of what was built was through ClickOps, right?

And we didn't actually start our cloud migration program until we were already in the cloud. So at the outset, a good chunk of our accounts were invited to the organization. They had existed before they weren't created properly. Our cloud center of excellence team didn't have access to them. There was one account that we had that was tied to an employee's AWS underpants account, and he wouldn't give us the account [00:22:00] because it had all of his Amazon music collection in it. Oh. Because the retail and the cloud were tied at that point. Project was spun up. We brought in a project manager to migrate things out of his account. Or out of that account, which was his account into a company owned account. So one of the things I'll say is architect for the Amazon you have not the Amazon you want. And then the Amazon that you have is going to improve over time. And one of the things, and I think Werner hit on this in his keynote this morning, but I'll reiterate it slightly differently is you have to go back and look at your architectural choices and what you've implemented every couple years.

Because Amazon may have solved that. So now you've got your solution, which has been working fine for you, and the Amazon solution, and you have to decide at what point do we deprecate our solution and adopt the Amazon solution. And it may be that the Amazon solution is 75 percent of what you need, or [00:23:00] even 50 percent of what you need.

Anything that comes out of re:Invent this week, I probably wouldn't say if I've already built something, I'm going to go home and, Q1 of next year, adopt it, right? It's not going to be there. Yeah. But you want to always go back and look at it. AWS config is an example of, I have been reviewing AWS config on my blog since about 2018, 2017, 2018.

Because I wrote a tool that did the exact same thing that AWS config did. At a 10th the price. And so it was like, what have they done? What have they improved? It used to be that it was only a handful of resources. I would be like, okay I want to know how many ECS containers I had.

My boss came to me with that question, an hour of looking at Bodo three and writing a Lambda function and boom, I gave him his answer. If I had been relying on AWS that, that would have been a PFR and having to talk to the service team. And when is it going to be released? So having that ability, at some point I [00:24:00] should deprecate that and adopt AWS config.

It has now a whole bunch more resources. It's getting a little bit better now on with periodic recording on the price. AWS config is still super expensive. I was going to say, yeah. That's the other reason I would not use Control Tower is it heavily relies on AWS config. And why your pet Control Tower is going to cost you a dollar or two a month.

Just when you log in, it's going to do a bunch of stuff and you're going to have to pay for every time you log in, from an enterprise perspective, it's a rounding error from a hobbyist trying to learn perspective, that $25 is lunch or dinner or something. So go back and review things.

I was in the AWS detective beta back when a Detective came out and it was a good service. And then they gave me the pricing and I was like, Oh yeah, it's not that good of a service. I need to go back and revisit it. I have not looked at Detective in a couple of years now. Security Hub. [00:25:00] I wrote a very scathing blog post a month or so ago about Security Hub.

And, they have now gone and actually fixed a number of the complaints. So I'm going to have a follow up to that. Unfortunately, Security Hub relies on AWS Config hasn't fixed my complaints.

Ashish Rajan: The reason I bring that up also is because the industry change is one thing, but the financial sector, or maybe a lot of the developers and builders work on the CLI quite a bit.

And we started the conversation by saying, hey, just go for an Identity Centre you have a local identity store, no need for IAM users. So automation is only through Terraform. But Terraform requires you to have a IAM user or an IAM role?

Chris Farris: No, you can use a role. You can use a role? Oh yeah, totally you can use a role.

Ashish Rajan: No one in the organization would have a CLI access at that point in time?

Chris Farris: No, Identity Center supports CLI. Yeah. Oh, yeah. I type AWS SSO login every morning. Yeah. And I can get into most of my accounts with, and With MFA? [00:26:00] So what happens when I type AWS SSO login? Yeah. It opens my browser. It's redirects me if it's my corporate one, it'll redirect me to my identity provider.

In this case, Google Workspace. Yeah. I authenticate to Google. I enter my Google password, my Google MFA. It does the SAML dance and then it stores a Identity Centre credential that I can then use to request IAM, ASIA, key ID, secret and session token. Interesting. Okay. Yeah. So I type AWS SSO login and I can do it.

I have a little thing in my shell that does sets the default profile environment variable and sets my. Bash prompt. Yeah. So I always know what AWS account I'm in because the last thing I want to ever do is type Terraform destroy and prod. Oh, yes. So I've got clearly on the command line what account I'm operating in.

Yeah, because it's literally the shell prompt is [00:27:00] an environment variable and AWS default profile is an environment variable. So I just linked those.

Ashish Rajan: Would you say how would that work for the whole tests and prod conversation? A lot of people have and maybe scaling up to Like I'll go back to the OpenAI example.

Suddenly the startup that they're working for and obviously still building on the foundation, the cloud security program. We've gone down the path of OK. I have Identity Centre I have organization. I have Cloud Trail and I have Ashish suddenly started as a cloud security engineer and trying to build some environment for myself or for whatever reason as I build and deploy them as a scale them out.

CLI or doing some testing is required in a quote unquote test environment where most people go. I need an AWS account without the complication of all of this. And I don't say that this is complicated way, but it just because when you are talking about scale, you but I have always done just one Ashish there's 10 Ashish

Chris Farris: and well at AWS organizations really helps with that, right? It's going to console, click, create a new account. It gets [00:28:00] added to AWS Identity Centre you add it. Send yourself to the group for that new account and and so you can say, Hey, In production, my builders should only have read only access or a specific level of access in development.

They should have a different level of access. And then you create a sandbox account, put it over there with maybe different service control policies, different governance and let them sandbox stuff. Yeah. And one of the things we did, the first company was we would set up program called AWS nuke that every Friday afternoon would delete everything in the sandbox account.

Oh, one, if I spun up an expensive EC2 instance or a SageMaker or whatever, because I was playing around, it wouldn't run for three months before, somebody in finance said, what the heck is this bill? Yeah. But two, it forced developers to then migrate from that sandbox account into a production account because they knew if they created something, they could not use it for production because it would [00:29:00] go away.

Ashish Rajan: I love that because that's a really good principle for people to do, to your point, build for what is right now and maybe plan for the future. i'll probably add that in there.

Chris Farris: It's not plan for the future in, okay, bring together a conclave of the great minds of the company and do a six day off site.

It's okay, we need to move quickly. What are the few things that we can do that don't box us in a corner and in some extent. That all comes down to somebody who has a little bit of experience having done this before.

Ashish Rajan: Yeah. And another layer to this is also the conversation about starters would not even know what a cloud security engineer does or what would be the point of having one when I already have a cloud engineer who's building my application. How would you differentiate between the builder role that we, as Amazon calls it, versus a cloud engineer? What would be as they scale the company go to the next level? What does a cloud security engineer do?

Chris Farris: Very good point.

All builders should have some level of [00:30:00] cloud security engineer as part of their function. It's not hire somebody like you or I and will come through and go and add the encrypt this database to the Terraform you're writing. Our builders need to know ahead of time. Go and encrypt the database.

Go and make sure that 3389 is not open to the world. Oh, I need to access this. How do I do that? Then that becomes a little bit more of building those levels of capabilities. Okay, I need access to this. I've got a remote workforce. I don't know what IP addresses they're coming from. All right.

Now we need a VPN. Yeah. Or we need some kind of tail scale. Maybe it's a bastion host, whatever, building those capabilities. That's more of a DevOps function than a cloud security function. Yeah. So it becomes educated and empowered builders who understand some of the security risks.

And then there's folks like us who [00:31:00] are researching it more, who maybe can sit down with you and have a conversation of, okay, You know, I need to have 22 open to the world. I don't have, budget for a VPN system and then talk through the risk and reward, talk through the threat model of things.

We almost could become emotional support cloud security engineer sort of thing that a developer could lean on, but the developer needs to be responsible for it. And then we would come back through with, okay, here's where we're going to define corporate best practices as. Here's how we will partner with you to put those best practices into the CICD pipeline before it goes to production in a larger organization that's a little bit more mature.

Now we're starting to talk about writing the standards and how do we enforce the standard and it's more than just, Oh, let's run a cloud security posture monitoring tool. And. [00:32:00] Fling spreadsheets out to VPs with here's all your problems. We want them fixed next week because that's not the way that developers want to interact with security.

They don't want to be told about problems and extra work that they have to go fix because they're more or less going to ignore you and you're not gonna have a clean relationship. I've come in and done the build a new cloud security program in a kind of brownfield environment, and my recommendation for anybody in that role is it's Don't start with a C S P M or let me rephrase that actually start with a C S P M, but keep it very close to your chest.

Run the C S P M. Look at the findings and if there's something like absolutely egregious, Oh no, here's a windows machine. It's windows 98. It's got 33 89 open to the world. Let's go fix that. I've got a publicly writable S3 bucket and it's serving javascript content to my consumers. Let's go fix that.

But once you've found those and closed those big gaping [00:33:00] security holes, look at the CSPM findings more holistically and you'll find patterns like, Oh, we have a lot of things with public IP addresses that are getting flagged by the CSPM. Why is that? Ah, because we don't really have a network engineering function that figured out how to allow people on their machines to talk over RFC 1918 space to the resources. So the developers, Ian Malcolm said it in Jurassic Park, life finds a way builders will find a way and they will find a way. And that usually that is, okay, give the RDS database. I need a public IP address. And then I can act on 3306, maybe they did the right thing and they have an allow list of only their home IP address that can talk to the database.

Yep. It's not an optimal solution. It probably hasn't blown up in their faces yet, but they did it because they didn't have the capability in place. [00:34:00] So use the CSPM data. Yeah. Not as here's a list of things to go fix. Hi, I'm the new security architect. Here's the list of things to go fix. I'll follow up with you in two weeks, not even, paying attention to your sprint cycle, look at it as.

What systemic things can I interpret from this data and then go target those and then go all the way back to the builders and talk to them about risk, talk to them about how breaches happened. So one of the things that I've done this year is I created a website called breaches.Cloud and my intent there was to document kind of a root cause analysis sort of thing.

Public cloud security breaches of specific companies. Whether it's Uber, or Chegg, or I can't remember some of the other ones on there. Yeah. And I try and find primary material, which tends to be, somebody was being prosecuted, [00:35:00] the FTC is going after somebody, and there's an indictment, so there's a clear complaints in there that's evidence of, okay, this is what we know.

And in a lot of cases, like in the case of the Uber incidents, that got a lot of publicity because the CISO ended up getting criminally prosecuted for something. Yeah. But as part of all of that, They talked a lot about what the root causes of the uber incident were, and it started with public access key and GitHub and attacker found that and that led to the FTC putting some consent orders in place with Uber around things.

The second incident comes along and it's almost the exact same thing. Long term access key in a private get hub repository because the threat actor managed to compromise an individual engineers GitHub. That engineer had access to Uber. He cloned a repo, he found an access key, he got back into their account.

All of that to say [00:36:00] is this is why access keys are bad, and please don't, create them. And if you do create them, please don't put them in GitHub. Or GitLab, or Bitbucket, or any source code, store your secrets appropriately, because if you just put your secret on the internet, it's no longer a secret, it's a string.

Things along those lines. In a lot of cases, there were one example of a company that was sharing the root credentials to their AWS Account

Ashish Rajan: so they can use this as a inspiration for breaches.Cloud could be, Oh, cloud security engineers can focus on that for this is what we need to learn from.

Chris Farris: Yeah. So it becomes a lot more compelling story. Yeah. When I say Uber got breached because of X, Y, Z rather than well, AWS best practice says do X, Y, Z. Oh, actually, yeah,

Ashish Rajan: that's a good point. So why would someone react to this? Yeah.

Chris Farris: Yeah. So it becomes a much more compelling story. If I can put a corporate face behind an incident. So don't use root access keys because this company did that. And this is what happened, so there was an example where an engineer, six months [00:37:00] after leaving the company, ran a Terraform destroy and took out several hundred EC2 instances that were running Cisco Webex. Now he got prosecuted, if you read between the lines.

Why did somebody who had already left the company for six months still have the ability to do a Terraform destroy?

Ashish Rajan: Yeah. So we'll come back to the part where some Cisco WebEx also happened, which is again, access keys. Yep. Or actually the user was there for longer. To what you said, I think we have a general theme for people who are in that startup and I guess growing phase of their technology stack in cloud, specifically AWS.

What kind of cloud security program they can have when they grow a bit more and add into the team. What kind of cloud security engineers can they do as well? And we spoke about the top three things that they can look at now to hopefully reduce the risk considerably for the future. And the fact that adding debt would just mean you have to pay the debt interest on the debt somewhere.

Chris Farris: And the interest on the debt tends to be [00:38:00] in the form of risk. Yes, perfect.

Ashish Rajan: So definitely feel like we need a part two of this entire conversation. But maybe I think a good place towards the tail end is just education around this as well. Where do you recommend people go for? There's a lot more we can talk about this and I think we can spend another couple of hours.

So for this particular episode, I think, where do you recommend people go for learning a bit more about cloud security specifically? Obviously, we'd love for you to talk about fwd:cloudsec as well. And what are you doing from AWS Hero perspective? Where do you normally send people to learn about cloud and cloud security?

Chris Farris: A little over a year ago, I would send them to Twitter. And unfortunately a lot of InfoSec Twitter, but not all of has decamped to Mastodon or LinkedIn or other places. There's still a decent amount of InfoSec community on Twitter. There's a lot of InfoSec community on InfoSec Exchange.

fwd:cloudsec is a great place. The Cloud Security Forum Slack [00:39:00] is an excellent place. And I think we can include a link in that. Yeah, I would do that as well. Yeah. fwd:cloudsec is our annual security conference of these are the hot trends in Cloud security. It's moved above and beyond.

How do we implement least privilege or don't use access keys to? Okay, here are a number of ways of discovering undocumented APIs that Amazon is using in the AWS console or here is how You know, I found this cross account or cross tenant vulnerability in Azure's Cosmo DB very high level or very top tier kind of stuff To some extent, does that help you solve your side of shared responsibility, which is, what I think is important, Amazon is a very big company.

They have a very strong engineering culture that gives them, I think, some certain level of blinders around what the rest of us faced trying to get [00:40:00] cloud security implemented in our organizations, and so they will hide behind shared responsibility. In many places, and they're doing better at helping us.

I think there's more to be done, but I would say, obviously fwd:cloudsec. This podcast, what, it depends on your form of, how you like your information too, right? Risky Business has got a very interesting newsletter that I read a lot. Yeah. There's the Cloud Security List, which I think is the one that comes out on Sunday.

From Marco. That's Marco's list.

Ashish Rajan: would you say TLDR:sec??

Chris Farris: TLDR sec is a little bit. It has a cloud security section, but it's a bit broader with app sec and container security and some things like that.

Ashish Rajan: Would you recommend the training from AWS? I don't know. Have you attended one of those?

Chris Farris: So I've done the AWS certifications. I definitely would recommend the AWS solution architect associate certification because that especially as a [00:41:00] person who is an internal security solution architect to my environment. Yeah. It gives me a sampling of all the things that I may or may not need to know. So that at least when somebody comes at me and says, Prometheus, I have some idea that I think that was observability, right?

Yeah. And then, I can dive in a little bit deeper and ask, okay, so what are you trying to observe? And things like that. I don't know about their actual. Training, right? The one thing I will say about a lot of AWS solutions is they're focused on the AWS solutions. Yeah. Yeah. And if you look at a lot of the blog posts and samples and things that come from AWS, it's, I'm going to use code commit and Athena and this and that.

And it's okay, so all Lego blocks, but I've got some other linking logs and mega blocks over here. How do I integrate that with my slightly more diverse ecosystem of things. And I don't use Athena for CloudTrail. I put my CloudTrail into Splunk and [00:42:00] I will do my Splunk queries.

You won't get that level of training from AWS. Interesting. So I would say that there are a number of outside organizations if you've got the budget. SANS has a great program around cloud security training, and they will go multi cloud. So it'll be a six day thing, and they'll hit Amazon, Azure, and GCP.

Get the whole gamut. Yeah, all at once. And they'll hit on the core concepts, and then they'll look at them as they apply to the three different clouds. You can't afford a SANS class. Probably most of us, there, there are other sessions.

Ashish Rajan: There are lots of content on YouTube. Bootcamp, all of them. But, that was most of the technical questions I had.

I have three fun questions for you. Okay. What is something that you're spending most time when you are not working on cloud?

Chris Farris: At the moment, I am hanging drywall in my daughter's condominium that we've just bought. Oh. And trying to figure out, how do I mud and tape and sand [00:43:00] and all of that.

Oh, home projects. Yes. So home project, when I'm not doing that, I love travel. And so whether it's, touring Bruges in Belgium or, driving to castles in Luxembourg, that was, a good chunk of my summer, travel is the other hobby I have. And it's nice because then I go and I speak on cloud security and I get to see the world and

Ashish Rajan: yeah.

That's pretty awesome. Final question. What's your favorite cuisine or restaurant that you can share?

Chris Farris: It's always going to be a bounce between either a really good steakhouse or a really good sushi place.

Oh, maybe combined. Sushi and steak. Actually, one of the best meals I ever had was a couple years back here at re:Invent. I don't know where it was. Maybe it was in Caesars. And it was just an Omakase kind of thing. Yeah. The first thing came out, it was some sushi thing with gold flakes in it. Oh.

And then the last course was, they brought me this big hot rock and a couple of strips of Wagyu beef. Oh! And tongs, and I was just like [00:44:00] I put the beef on the really hot rock, cooked it to my temperature and ate it. And I want to say that my meal was 600. Oh, wow. Yes. And that was perfect because it was me and a friend and we were like, We don't care what it's going to cost and we're not going to bring a vendor along to buy it for us.

We're just going to have a quiet evening catching up.

Ashish Rajan: Yeah, nice. I love that. And I want to add a question as well, which I've been doing for people who are experienced. And especially because we're almost entering that point where a lot of people are almost starting their career in Agile. So just to, so that we don't forget waterfalls, for lack of a better word, What is something that you miss about waterfall that you don't see in Agile?

Chris Farris: Something about waterfall that I don't see in Agile.

Ashish Rajan: Or is there something you miss about the waterfall days?

Chris Farris: I have had a lot of experience with what I would describe as Agile fundamentalists. Where, hey, I found a problem. We have to do something. And the pushback from the scrum master or the [00:45:00] product owner is it's not in the sprint.

We can't do that. And I think within waterfall because waterfall was longer time frames. Yeah. There was a lot more ability to, Oh, something has changed and pivots in a shorter timeframe than, Oh we've already planned next sprint. So we'll get to the two sprints from now. And it's like a two months later, two months later, and we're still like, okay we have this RDP open to the world, We probably have been ransomware and they're just waiting to, hit us sort of thing.

And I'm not a fan of Agile so much as I am of Kanban because I feel like, again, maybe it's just been my experience with some of the Agile fundamentalism. Yeah. That Agile is almost now as restrictive as what maybe we were doing in the What if my career started in the 90s? In the 90s and early 2000s around, just Process.

Yeah.

Ashish Rajan: Yeah. It's like the whole there's a cab. There used to be a [00:46:00] cab. I think it used to be called. Oh,

Chris Farris: change advisor. So that's ITIL. Yeah. I wouldn't call that waterfall. I would call that the ITIL. Yeah. Because there's

Ashish Rajan: ITIL days as well. Also ITIL, Waterfall, and then now Agile and Kanban.

Chris Farris: That's my favorite quote was a VP who said.

At one point, and this was probably right as we were beginning our cloud migration, they can go to service now and open a DevOps ticket, and I was like, Whoa, okay. You absolutely do not understand the concept of DevOps. If you're going to service now and yes, previous people who I've worked with will know my opinions of service now.

It is definitely not what you know, a modern cloud company should do. That said, it is absolutely imperative that you have communication channels going across your organization. And I think change advisory board to your point was created to ensure that communication happened, [00:47:00] but it. Then became a we have this meeting once a week and oh we didn't get to your change.

So it gets pushed out. Oh, yeah. Next thing you know, hey, we haven't closed this firewall hole that has 33 89 open the world, so a more GitOps flow the ability to say, Hey, I'm committing this change. I'm pushing this change. People can see What has changed is important. And then I think that there's just the need for people who can look at things broadly and have time to look at things broadly and know that this team is doing this and this team is doing that and that this change might have an impact to that team so that it's not this team who is heads down trying to deliver a feature and this team heads down trying to deliver a feature.

There's some level of enterprise architect over all of them who can facilitate communication. Yep. And that was one of the things I loved about doing the security work is I was talking to all of the different parts of the business and I was like, Oh, [00:48:00] you're trying to use this you should go talk to him.

Who's also trying to use that. And that we were making connections across the company because the security team was the one common team across the company that everybody was dealing with.

Ashish Rajan: Thank you for sharing that. That's pretty awesome. And where can people find and connect with you online to talk more about this space and maybe talk more about their experience of Control Tower as well.

Chris Farris: So if you want to hear about Control Tower, you can follow me on Twitter and Mastodon. At J. C. Farris on Twitter. At J. C. Farris at InfoSecExchange on Mastodon. Chris Farris on LinkedIn. Annoying Cloud Security Nerd and AWS Security Hero is I think how you would find me on LinkedIn. ChrisFarris.Com has a link to all of those.

And then, yeah, I'm on a cloud security Slack forum too. If you're interested,

Ashish Rajan: I will definitely put links to that as well, but thank you so much for coming on the show. I really appreciate this. All right. Awesome. Thank you. Thank you. Thanks everyone. We'll see you in the next episode. Peace.