Rich Mogull: [00:00:00] I describe multi cloud as it's like becoming an adult. It's the worst decision you'll ever make and it's going to happen anyway.

Ammar Alim: Yeah, I don't think you should ever put like a multi cloud in your resume. Like serious cloud, people are not going to take you seriously.

Meg Ashby: Anytime someone is yeah, you should learn another cloud.

I'm like, how about Kubernetes?

Rich Mogull: Now there are strategies. If you're that person, stuck in the bad position. Not everybody has the freedom to quit their jobs and start a podcast. My entire job is to keep up on this stuff, and I can't keep up on this stuff. And that's what I get paid to do.

Chris Farris: The people at AWS are awesome.

AWS, as a collective, is almost hostile to some of its customers when it hides behind shared responsibility.

Ashish Rajan: Welcome everyone to the State of Cloud Security, the Community Edition. We have got a lot of guests over here on both sides. If you can give a short 30 second intro about yourselves, and we'll keep going through this.

So I think people have some idea who are here, why they're here, practitioners, all of that.

Damien Burks: Hello everyone, my name is Damien Burks. I've been in the cloud security community or [00:01:00] industry for about 3 years. And in the cybersecurity or information technology industry for about 5 years, 4 years. And also I've been content creating on YouTube, video creator aswell.

Meg Ashby: Hey y'all, I'm Meg, I'm based out of New York City, and I've also been in the cloud security space for about three years.

Rich Mogull: My name's Rich Mogul, I've been in security for about 25 years, and in cloud security, however long ago 2010 or 11 was 13 years.

This is 2024 for context. Good at cloud, bad at math.

Ammar Alim: I'm Omar been in IT slash security for the last 15 years, more focused on Application security and cloud security for the last 10 years.

Chris Farris: Cool. Yeah, so I'm Chris Farris. I do cloud security consulting. I've been doing AWS stuff since I think re:Invent 2014.

So we'll say. I've been doing cloud for about 10 years now in security since we'll say 2017. So please do the math yourself. Awesome.

Abdie Mohamed: My name is Abdi, everybody. Pleasure to meet you [00:02:00] all. I'm a cybersecurity and cloud professional. I've been doing this for about five years. Really, my main background is GRC.

I've been diving deep into cloud for the past two years. I look forward to hanging out with you all.

Patrick Sanders: I'm Patrick Sanders. I've been doing software for 12, 13 years now, and I've been doing cloud security. Coming up on five years.

Ashish Rajan: So I guess the first question I'm going to throw in this conversation because we have almost such a spectrum of experience as well.

I'll start with cloud security for what it was when you guys started and where is it in 2024? So people can have some context for how much cloud security has changed.

Chris Farris: It's gotten more complex, it's still a lot of the basic things that are still happening. People are creating access keys because they can.

People are putting things on the Internet because the defaults are, insecure. So Gen AI is a thing. Blockchain was the previous thing. Serverless was the previous thing before that, but it all comes back to credentials and people [00:03:00] putting stuff on the internet that's unpatched and overly exposed.

Rich Mogull: Yeah. In 2011, it was exposed access keys. Now at that time there was only root access keys cause IAM didn't exist in AWS yet. There was publicly exposed resources being compromised. And then it was just virtual machines, because all there was like that and S3 buckets, and it was public S3 buckets.

2024, now it's not root access keys, but it's still access keys, and it's still exposed stuff on the internet, and it's public buckets.

Ashish Rajan: Awesome. So that was 20 plus years of experience. What about 5 years of experience on this side?

Abdie Mohamed: Yeah, so So yeah, so when I started in the cloud, an issue that I had noticed is, it's the same issue as on prem where you have a bunch of IT assets just hanging around.

It's So we have, accounts, AWS accounts, cloud accounts, just hanging around and nobody knows who owns what, right? What are we doing to decommission this account, right? And as you guys know, having accounts just floating around, that just creates more risk. And money. And money.

And money. And EC2 is just running. Yeah. Running 24/7 so I [00:04:00] think that's still a big issue the IT asset management side of security.

Patrick Sanders: I don't know how much I have to add to your things look pretty similar to when I started doing this five years they don't realize that making something public means making it public. There's still a lot of, a gap of understanding what the implications of some of these things are that we talk about all the time.

And tie it in with nobody knows who owns it.

Yeah, so who do we even talk to find out?

Damien Burks: On top of everything that they just said. One thing I'm starting to notice is, misconfigurations is big and scales across the entire platform. So a lot of people, when they deploy spin up services, they, click ups, is one of the biggest problems. So people aren't necessarily leveraging IAC the way they should.

And on top of that what I'm starting to see also, which has been a problem, but I think companies are starting to get better, is the modularization of some of the services. As far as, if, let's say, for instance, a team wants to spin up an EC2 instance, we should, as an organization, create modules around that with the necessary security controls embedded to help prevent misconfiguration issues from [00:05:00] happening.

And I think people are starting to notice that, but I don't think there's enough emphasis on adopting such strategies within an organization or an environment.

Meg Ashby: Yeah, I would say for me, I agree with what you're saying with the public S3 buckets. And I would say that also, I've seen it rear a very similar head in the Internet.

Also being a new way of exposing, again, I've put my resource on the internet. And I would also say, I've seen a rise in what I call platform esque services in AWS. It particularly popularity of things like SageMaker Managed Airflow, types of services, which I find a bit difficult to understand from a model of the difference between the infrastructure of the service itself, and then the very distinct components of what is more of the meat of the application, like the code that's running, the notebooks, etc.

Ammar Alim: Just gonna add a different perspective, which is, I also have [00:06:00] seen positive stuff even early on and you have to bring some context. Did they just hire a VP who was all in cloud governance or they didn't know much about that. Did they had to rush a migration and did they start with a shifted lift where they had a single account?

It's messy. So you have to bring in that context and bring in the customer, like the AWS user journey, like at which stage of their maturity and whatnot, but I've seen, early on in seven years ago. Serious multi account automation where people set up proper accounts. They give you three stages dev, production i've seen that yeah, but today you still see that doesn't exist.

You still see a single account so many access keys

Chris Farris: Yeah, that's a function of data gravity, right? You can't just move an S3 bucket from one account to another you can't deconstruct a large multi account without massive, development effort and potentially even downtime.

Patrick Sanders: I was just going to say, [00:07:00] some of my former teammates call those account anchors.

Things that keep you from being portable across accounts.

Ashish Rajan: Something that I've noticed over the years is that now suddenly, There's this rise of multi cloud people as well. And it's not by design, but by requirement, is how I would describe it. Like most organizations these days, earlier, like when we started the podcast, we would talk about AWS, Azure,, Google Cloud.

Now there's Oracle Cloud, people talk about IBM Cloud. I'm like, is that even public cloud? I don't know. I think, because I think especially because we only talk about public cloud. We're like, yeah, they have a public offering. I don't know. No. Yeah. But the point being. As that's moving, and all of us obviously have other colleagues who are in this space as well, is the expectation from the industry that most of us should be multi cloud?

And we should know, hey, AWS, Azure, Google, Oracle, IBM. I don't even think that was like a possibility on premise.

Damien Burks: I think so. And the only reason why I'm saying is because this thing I'm starting to see float around is called concentration risk within AWS within certain cloud providers. And that risk kind of [00:08:00] scares leadership because I guess, for example, there was a point where things went down in certain CSPs. And when things go down, of course, production apps go down, start losing money, start losing revenue. So the idea came from, okay if we're cloud native, but we don't necessarily want to have everything in just one CSP, we don't want to start migrating things into different CSPs. So looking at it as more or less like a fault tolerant way of making sure that everything's still running.

But the problem is that there's a lot of different services in different environments, and then they all work very differently, even though it may seem the same way is very different as far as how to specialize in it, so I think it really, there's expectation that you should know, but I always believe that you should specialize in just one and then know it at surface level so that you don't lose your sanity.

Patrick Sanders: The knee jerk reaction to those situations tends to be, some VP says, Hey, see if we can deploy half of our workloads to GCP instead of AWS. As cloud security professionals, we have a responsibility to help people understand that it's not [00:09:00] that easy. We're responsible for managing the risk of our cloud environments and splitting our workloads across multiple clouds.

Yeah, it may mitigate some risks, but it introduces a whole lot of other ones. Yeah, so maybe it's the right decision Maybe it's not but it's much more

Chris Farris: and there are other ways to achieve the availability in the CIA triad and then go to a completely different foreign landscape, which is what going from one cloud provider to another is

Rich Mogull: I describe multi cloud as, it's like becoming an adult.

It's the worst decision you'll ever make and it's going to happen anyway.

What I've seen in working broadly with enterprise clients, there's a couple of pathways. One is when they go the path you just asked about, that's a recipe for failure unless you triple your budget and not just your security operational budget. There's this myth of Oh we'll monitor like where it's cheaper to run workloads and we'll build some dynamic agents going to move our containers around the workloads.

I'm like, [00:10:00] just Kubernetes, your data migration, your data plan, your log monitor, your learning, your whatever Oh, that's going to fall apart. None of that work. I'd call it as mythical as a unicorn, but I guess in tech we have unicorns. So it's a mythical is like a, I don't know, a corner corn. So there's that angle of it where.

Exactly what you said. Everybody vastly underestimates the cost and complexity of working across multiple providers. The other side of that is the skills side. Before, we were making fun of it, where now there's the expectation, oh, we'll just have Bob and Alice figure out how to do GCP because they've been doing Amazon for a year or two, so they've got it down.

We're all of us are probably mostly on one platform. I've been doing this for

Ashish Rajan: 25 years. Yeah.

Rich Mogull: Security. I was doing cloud, before we had cloud.

Like I've been pretty hardcore in AWS for over a decade now. And when I come to re:Inforce, I talk with people and I learn stuff every day that I don't know. So I'm competent, I think on AWS, and I still make [00:11:00] mistakes. Azure I've been on for about 7 years, 6, 7 years, something like that. And I'm hanging on by my fingernails.

And I can't spell GCP. I don't know how anybody expects it, but we see people with resumes saying, Multicloud, Multicloud we see people requiring it for hiring. I guarantee you, there is nobody with that level of skill on all three clouds.

Chris Farris: And I've never written a job req that says, I want that, I want you to be proficient in one cloud and generally able to spell the other two.

Ammar Alim: Just to add we are talking about two things, right? We're talking about the need to do multicloud, which is a usually company decision. And the second thing is the cyber security engineer needed to be an expert on, be a multi cloud expert. Oh,

yeah.

Ammar Alim: For thing number one, some companies don't have a choice.

Your customer will tell you, if they're commerce driven, do not use AWS. Direct competitor We're talking about

Rich Mogull: Walmart. We all know that. We're not supposed to say these. Here we go.

Ammar Alim: You're right. You're on the right track. You may be forced to go [00:12:00] multi cloud. You don't have an option.

Ashish Rajan: Yeah.

Ammar Alim: I think in that case, since I think we agreed that you cannot become an expert across all these providers you do.

I think, based on my experience for what I saw. Is you be in the business of enabling? So there's a use case to use GCP. There's a use case to use Azure. Yeah. Yeah. The team that is operating these providers, you enable them, you make them experts. You're good enough to be able to provide governance.

Yeah.

But you're not going to be an expert. You just still focus on being an expert on your main provider. Like you typically have 90% of your workloads with one.

Ashish Rajan: I also feel there's side to it where we can't protect that we can't understand as well. How did we go into something to know enough? The governance part to what you said, maybe the people who say they're multicloud, they're all trying to say that I've done governance across the three, so I'm multicloud from that context as well.

I'm not knee deep into it. I just dip my toes into each one of them to know. What identity is like, what network security is [00:13:00] like, what backup is I may not be an expert, I can't implement jack shit over there, but I can definitely talk about the governance. So you're saying that's the second party point.

Oh, my career path as a multicloud person is that I can have that governance conversation, what that would look like across all the cloud providers. Is that how you're thinking about it?

Ammar Alim: Yeah, I don't think you should ever put a multi cloud in your resume. Serious cloud people are not gonna take you seriously.

Nobody should take me serious. I agree with that. Anyone who did cloud for more than 5 years

knows that it's hard to master all of them. Hundred percent. It's just difficult, right? Yeah.

So be honest. Just say AWS or Azure and say, I maybe know 10% here and there. Just enable your service team and empower them and enable security for them.

You're not gonna be an expert. They're close to their workloads. Give them the tools. Give them like the trainings, whatever they need. That's the only thing you could do.

Damien Burks: If your organization or your environment has on onboarded a particular CSP, you should fight to have one person who's an expert. Yes. At the CSP. Yeah. It's not generally exactly because at the end of the day it [00:14:00] eliminates that risk of people not knowing what it is that they're doing anyway. You will want someone who is an expert in cybersecurity for a particular CSP to be able to do those architecture review boards, to have those discussions, to ensure that you're doing things in the best way for the CSP in a security sense.

Rich Mogull: So this is literally the call I had that made me late to come over here. It was with a mid sized enterprise. It's going multi cloud and asking for strategic advice. And one of the problems with the SME thing came up, because that was the first thing I said, and he's subject matter expert for each one, and they're like, what if we don't have a lot on Google?

And I'm like is it your customer data? Then it just doesn't matter. And they're like that's not realistic for us to afford the SMEs. What do we do? And I'm like, you don't build your network with all Juniper and then hire Cisco people to run it. Like it's, That's what you're asking to do here.

Ashish Rajan: If you are not old enough They wouldn't even know what Juniper is over here by the way.

Patrick Sanders: If you can't afford the people you need to secure it, you can't afford the thing in the first place.

Chris Farris: Or you shouldn't [00:15:00] be doing it. The other thing that brings you to multicloud is mergers and acquisitions. That's an opportunity because, yes, if you're an AWS shop acquiring a company with GCP, Hopefully you're going to get a GCP expert as part of that deal.

That's where you get with HR and you get a nice juicy retention bonus because you need that person. Not only do you need their institutional knowledge of the company that you're acquired, but you need them to join your team and to cross pollinate.

Meg Ashby: I would say from my experience, anytime someone is yeah, you should learn another cloud.

I'm like, how about Kubernetes? I think that's a fair trade off. I tend to come from the smaller company background. So for us, the realistic thing is we say our cloud service provider goes down. We just say, we're sorry, man,

Ashish Rajan: I would love to help you. But it's not me, it's you.

Meg Ashby: For us, that is our been a lot of our stance.

And I think, especially when we're [00:16:00] looking at smaller companies, we very much have to take very seriously the time and effort of engineers and things. Like we unfortunately aren't in a position where we can really have anyone just It's playing around with things, unless we're really serious about it.

Abdie Mohamed: Yeah, I just want to, give a shout out to Damien here, when he brought up, yeah, you need at least one expert in another CSP, because it really does halt the business, creates a lot of mayhem. Yeah. If you don't have that one person. It's you're creating a basketball team, a big basketball fan, and you have nothing, you have nothing but shooting guards on your team.

Where's the center? Where's the point? You need someone, at least one person.

Ashish Rajan: You need one Kobe Bryant. One Kobe Bryant? Yeah.

We didn't speak about incident response as well.. Because I think the multi cloud model fails if you don't have an SME in. So for example, we've still got multicloud as AWS Azure Google Cloud.

But if you have a team of generalists, suddenly there's an incident. And now people are like, should we ask ChatGPT? How do we proceed from here? I think that's where it falls over. Because I think it's always good for us to think about the positive scenarios. Yeah.

But, if we live in the world [00:17:00] of trying to prevent incidents

Rich Mogull: the reality is most of those organizations, and I've dealt with many who have that, they just They're going to call a third party incident response firm at that point. We've seen that. We just saw public announcements from multiple about a breach in another cloud thingy.

We're trying not to name names. Yeah. In orgs I've worked with, that's okay, we're in over our heads. We're going to call somebody for help. The problem is that's going to cost you probably three times the annual salary of the SME that could have prevented that in the first place.

What do they call it? Cross functional teams?

Ashish Rajan: The funniest when I was talking to a CISO about ,they said they wanted to build a multi cloud team So I think I just tried describing it like Hey, it's like how you know how to drive a car But you've been asked to drive a truck now But isn't that still driving?

It is still driving, but it's different I think the understanding to what you said Patrick earlier It's our responsibility to help the other side understand that, hey, the complexity every time you move a cloud, and we didn't even touch on Kubernetes yet. I guess people who are watching and listening to this, they probably can take away from the fact that the moment their organization thinks about multi cloud [00:18:00] or, hey, we want you to do multi cloud, suddenly it's you're asking me to just give up on something and go deep dive into something else completely or you are hiring someone else.

Rich Mogull: Now there are strategies if you're that person stuck in the bad position. Not everybody has the freedom to quit their jobs and start a podcast.

If you're stuck in that position, there are mitigations you can do for yourself. One is We all know IAM is the root of all good, and the root of all evil. Go in on IAM, and again, this goes back to what we were talking about, it doesn't matter if you're on Google, Amazon, or Microsoft, it's public stuff, and IAM misconfigurations. and public storage.

And so if you focus on those, the smaller stuff, like this stuff, Chris and I hang out with, I haven't worked with you guys as much, but we like, we get into [00:19:00] like weirdness around weird edge case things and stuff when we're having fun talking about stuff but it all comes down to the end. Those three things,

Ashish Rajan: The multi cloud thing was an interesting one because the reason I brought that up is because you almost see the theme across the board is I look at conferences as a way to realize what's going on in the world as well sometimes. And I think I imagine a lot of other people do as well.

This whole KubeCon that's been running for the past four, five years, they, I think this year they had the Europe one as the largest ever Kubernetes conference they've ever had. And they said most people were practitioners. Until 2023, most people who used to come to KubeCon, used to be people who used to maintain those open source repositories.

This was the first year they had people who were using it in organizations like submarines, whatever, flight, whatever, and going. Who are these people using this in life? And meat factories, is there something that you see as upcoming that you're spending a lot of time or you're preparing yourself for?

Hey, come end of year, if I'm on Thanksgiving holiday or Christmas holiday, I'm gonna sit down probably, start looking at this particular [00:20:00] topic for whatever. I'm gonna start

Rich Mogull: You know we're all gonna say the same thing, right?

Chris Farris: That one is off the list. Yeah, that's right.

Ashish Rajan: Outside of that, two letter word.Which we'll sing in the end together unanimously.

Patrick Sanders: I have been spending a lot of time around isolation. Earlier on in my cloud security experience, I was maintaining an open source project that takes permissions away when they're not used. That was great, like it was written by somebody on the team before me.

Really cool tool, it's awesome. But it's not where I see things going, because instead of taking away individual permissions from something that's amongst a ton of other things that are in really bad shape, if we could move those things to be isolated amongst themselves, they can have whatever permissions they want inside of their little box, and they can't affect anybody else outside of that.

Abdie Mohamed: Yeah, I think for me, something I see myself focusing more on is just more front door governance. Shifting left, ensuring that the guardrails are already there. [00:21:00] Make the developer's life easier. That's something I'm always thinking about. Instead of just pointing the finger at the developer.

Hey, you go solve this, and I disappear. Give them an opportunity to develop real fast without having to worry about the little things, the compliance and all that. Instead, what I'm trying to do is do my best to make sure that the environments that they're using, all of that, it's bulletproof as much as possible there's no such thing as 100%, compliance or 100 percent security, but just trying to make their jobs easier, that front door governance that's something I see myself diving into.

Chris Farris: I'm going to say Kubernetes because, I've not touched it. This is what you millennial kids say. You're like a copy of Kubernetes. My technology in the cloud path went from physical servers on prem to VMware for a few years, to, hey, we're going to go to the public cloud and let's do Lambda. We bypassed EC2, we bypassed containers, and went straight from VMware to on prem to Lambda function. So I've done a couple of Docker files, but not a lot. So I really do need to [00:22:00] understand and dive deeper into Kubernetes because, Hey, did you know you can actually publicly expose a Kubernetes API endpoint in AWS and I want to poke at that and be able to articulate for my builders what that means.

The thing I like doing is articulating the risk to builders until I can break something. And until I've walked not a mile in their shoe, but at least 20 feet in their shoe building a meat factory in Kubernetes, then I don't know it yet.

Ashish Rajan: Did you know it's public by default? Kubernetes is public by default?

Kubernetes API is public by default. Okay. Awesome.what could possibly go wrong that's the funniest part.

First I'm like, wait, what?

Ammar Alim: Yeah, I think I mentioned it to you yesterday, but what I'm focused on these days is Edge security, which Yeah. Anything, I define that anything between the user, client, laptop, or device, and the public subnet.

So I don't care about what's in the private subnet, public subnet. And the reason for that [00:23:00] is not all product teams use just like CloudFront, ALBs, and stuff like that. They could bring in CloudFlare workers, Akamai CDNs. There are complicated use cases where they put AWS connected to Akamai to deliver applications.

I don't want to mention the word, but I have to, which is AI at the edge. We're supposed to say it together.

Ashish Rajan: That's not good. Everybody drink.

Ammar Alim: This is my area of interest for me these days. What's happening on the edge gateways, that you custom built to deliver and stuff like that, that accept user traffic. There is complexity of the path, like how many hops, yeah, does the request touch before it's fetched data from S3 or database or something?

This is my perimeter security but on the edge. Probably.

Chris Farris: And that's super important as we talk about multi cloud because one, multi cloud and multi [00:24:00] CDN Would you say multi CDN is complex too?

Plus, now you're multi CDN and you're multi cloud. That's a very key area to dive into.

Resume updated, multi CDN expert now. There we go.

Rich Mogull: This is, it's tough because there's a half dozen different technologies I'm constantly like working on and trying to put my skills on. I think my biggest focus effort is on community education right now.

So not a specific technology, but taking all this crazy stuff that we've learned and simplifying it and making others help learn that and then on the tech front, it's the Voldemort. And Kubernetes, I've done some with, but not enough. I've been really fascinated. And this was spurred by a work project I didn't expect, with some of the CNI, the network aspects, and combining the network controllers and the different layers that you can get.

So with Cilium and kind of some of those different models of the network stack. And then looking at combining it with SPIFFE SPIRE and getting into some of the zero trust aspects where [00:25:00] we have identity network traffic and we're making policy based decisions. And that's why I'm hesitant because there's a bunch of techs coming here like Cedar can come into play for authorizations within an app that has awareness of network and endpoints and dealing with the distributed identities pieces of it.

Meg Ashby: Yeah. I feel like that actually is something that I have been stuffing in the back of my head, the whole SPIFFE SPIRE and that sort of granular level of controls of Kubernetes. I'm still going to put that in the back corner. In addition to the SageMaker Airflow, those sorts of platforms I mentioned earlier, I'm also thinking a lot about egress solutions and I would say egress solutions that actually make sense.

I feel like I hear a lot about egress solutions that really only solve half the problem and I find that I get really concerned about the non traditional egress paths that I think are the most dangerous but also the most unsupported in traditional patterns. So for me it's about [00:26:00] egress patterns that kind of are a bit more holistic that sense.

Damien Burks: I think My biggest thing, so I'm really starting to focus on right now, is really multi cloud, cloud incident response control development and engineering, in conjunction with threat modeling. I think threat modeling is something that there's not a lot of discussion about, and it's quite overlooked, honestly, in the cloud, because there's so many different risks that pop up with each individual service.

And as somebody who has development experience I believe that's where my passion really lies. I was building those types of controls to help put out those fires and help aid our incidents responders and whatnot. And of course, always continuing education is definitely a given with that because always going to be learning something new.

Yep. Awesome. Thanks for sharing that.

Chris Farris: I'm surprised nobody was talking about, the post military quantum grade encryption stuff that was available in the new Grafton processors.

Rich Mogull: I'm going to defend post quantum crypto, and the reason that especially the banks care is because the stuff they encrypt today [00:27:00] will get exposed once, in like that, once quantum, like once crypto, or quantum Grafton comes into play.

So they've gotta, you have to do that now, because if you wait until the quantum computers are there, which by the way, who doesn't think the NSA has one?

Chris Farris: They've stopped complaining about an encryption, so they probably haven't.

Ashish Rajan: I guess we've been talking about all our experience and all our sides of the story.

Do you feel there is something on the other side The cloud service provider. I don't want to name any. We've got five now. I think there's been a general sense that there could be more done by the CSPs across the board.

Chris Farris: I think there's a large report from the United States government about that.

Ashish Rajan: Yeah, because it's like the same thing. I used to get frustrated when people would say, Oh, we want to charge you extra for 2FA. And I'm like, what do you mean you're gonna charge extra for 2FA? It should be, security is number one, so why is that expensive? But, I'm curious if you guys had, and this is for anyone, basically, are there things you noticed I have one, which, if I give it out, then I was gonna be very obvious which CSP it is., so I'm gonna stop, not talk [00:28:00] about it.

Rich Mogull: I'll take the hit. Microsoft's a national security risk. It's not me making it up. That is, the federal government has said so, and it has been called out for not being as mature as the others. Now that said, they all have their various issues. We've talked earlier about secure defaults, like making it So I'll give you an example.

When I first started on AWS, when they first released, when you launched an instance, the Launch Wizard security groups had no access. Port 22 was not open by default. Amazon had to turn that on later because 9 out of 10 people launching an instance would call Amazon support saying I can't log into my instance.

That was a secure default that had to be changed due for customer reasons. So I think we have to admit all of them can be doing things better and they are adding so much complexity without being able to pull the puzzle pieces together that experts like us, my entire job is to keep up on this stuff and I can't keep up on this stuff and that's what I get paid to do.

There's no way you can keep up with all of the latest and greatest. So I think, I'm not saying slow innovation, but I am saying accessibility on the security pieces. [00:29:00] And we have one that structurally now I also know that they have that problem because I use recall and it showed me all their old problems and another little job.

There's cultural issues there that need to be dealt with as well. So room for improvement across the board. One is really standing out now and it's important because they're so vital. I use Office 365. I use Xbox gaming and all this stuff. We need them to be better. We need to encourage them, we need them to be secure, and they have very smart security people in there.

It's just that they've been pushed. It's a cultural issue.

Ashish Rajan: Is doing security better in one over the other? And feel free to name CSPs if you like. Yeah. Which one stands out for you guys? For me, AWS. AWS is the one I'm deepest in.

Damien Burks: And for you?

I would say AWS because GCP, I feel dibble and dabble in it, but I just dont understand how to do anything secure.

Rich Mogull: There are actually two or three things in Azure, but they do better than AWS. So the RBAC model, you can never [00:30:00] get to the granularity of AWS. But the application of it from the top down from the beginning is easier. So there's a low reduced complexity to get to an okay. You still have to get much deeper.

You have to pay for custom policies. You have to be on the right support level to get those, which is garbage. Or you have to pay more for denying policies might still be in preview, but for an enterprise person with low experience coming in, if you go to AWS. Yes, the foot guns are pointed at your head.

If you go to Azure, the foot guns are pointed at your feet. Then, Azure policy actually works well because there's a lot of them built in. And they have alert policies. It's not all block policies like in SCP. So they've got a bunch of that built in. So it's not all bad. But it's still, there's the more fundamental issues.

Damien Burks: There's also one thing I'd like to point out. And I've spoken with various different security leaders within various different CSPs and one thing I want to point out is that there is more community support for AWS's environment that allows for people to be able to implement security solutions at a rapid pace versus [00:31:00] other CSPs because of lack of documentation, lack of community support.

Chris Farris: The open source community of AWS is massive.

Patrick Sanders: Yeah, they had a head start, yeah,

Chris Farris: that's right.

Rich Mogull: But we have a cloud security community we all participate in, and which CSPs are represented there.

Patrick Sanders: It's weighted.

Ashish Rajan: I think, now talking about the protection part, I find interesting how the licensing model, because I've got a few rapid fire, as I want to call them, things that I feel a lot of us in the community hate, and this is on the tail end as well now, that, what do you guys think about the way people get licensed? By the consumption, like you know how to find about the privacy thing, and you mentioned the Microsoft license. If you don't have E5. They basically don't have anything. So when you go for Amazon, you pay for what you consume. If you go for Azure, you basically if you have E5, oh great, otherwise you can upgrade to E5 get all the security features in the world including DLP, all of that.

So it won't keep the Chinese out. Yeah. There is that, but [00:32:00] I feel like is there one thing that bothers you about any of the Cloud Service Providers

Abdie Mohamed: It's not like a specific service, but I feel and this is for all of them, I feel like the cloud service providers can communicate a bit more. Again, they do talk about the shared responsibility model.

They don't talk about enough how the shared responsibility in my book is a little different depending on the services that you use. I feel like they can do a better job of communicating that.

Ashish Rajan: So developers would not understand that easily because they just draw the line in the part. Yeah. They think it's oh, that's your diagram, I guess that's Yeah, exactly.

Abdie Mohamed: Yeah, exactly. But, the responsibility that you have could be 70 percent and theirs could be 30 percent depending on the services that you use. Yeah. Some services, you have managed services and some services are not managed, depending on the service that you use, it's going to look a little different and understanding What's your responsibility?

It looks like depending on the service. It's very key to having a healthy posture in terms of security.

Ammar Alim: The thing I dislike, I also like sometimes it has nothing to do with support or engagement or anything is AWS makes it [00:33:00] very AWS. It's like purchasing furniture from Ikea. You have to bring it all together.

If you want to host a website on AWS, yeah, there's 17 ways of doing that. That gives developers so much flexibility and anyone can do anything. It's also fun when you're building. If you're building a solution, there's so many ways to get the job done. It's a creative way of doing something.

But it's makes security difficult. So when I'm building, I'm having fun because I can bring pieces together and get something done. Developers get to do that as well. But if you come to secure it, you're in trouble. It's hard.

Rich Mogull: One of the most impactful things the cloud providers could do that they don't do today.

Every provider should give you basic CSPM for free. Just flat out.

Yeah. I built a commercial CSPM platform and I still work for a company that sells that. And I still think it shouldn't exist. Let the third party vendors do the more advanced stuff. If you think about somebody coming without a lot of cloud [00:34:00] knowledge starting to experiment and how quickly they can make mistakes.

And I don't mean that they have to have an ISO 27001 and NIST 853 level support. It's the fundamentals. That should be free. It's not, it used to be free in Azure, it's not anymore. It's not free in AWS. And if you use Security Hub, then you gotta pay config. And that blows that out of the water. pretty quickly.

Google security command center, you've got to pay for that. That's number one. Number two would be to support that some level of what we all know is GuardDuty, but some level of alerting misuse and abuse alerting. And we actually get some of that for really super egregious things in AWS. But if you're, if you go on Reddit and you look at the kinds of mistakes people make and the charges they get in the incident, if you work with enterprises, who are in, or even small businesses at lower levels, those two things alone would go a really long way.

The third was good SSO and AWS, and they, that one actually we can get now. [00:35:00]

Ammar Alim: One thing to to just get out, hopefully AWS is watching this. This two pizza thing is not working.

Rich Mogull: Yeah.

Ammar Alim: Like these people are not talking, this service doesn't talk to that service like I cant automate.

Yeah. So it's getting old and

Chris Farris: it is a complete lack of customer obsession on the part of AWS to have four different ways to describe a IAM call. Is it get, is it list, is it describe,

Patrick Sanders: also, there's literally nowhere that you can look to get a list of everything in an AWS account. No matter how much money you pay there's no one reference for that.

I

Damien Burks: think one of my biggest problems that I have is the limit on, or I would say the ETA for you to see when you made an API call in CloudTrail. It's not real time. And I think that from auditability standpoint, if I have someone who's making an API call assume a role that's not supposed to be, assume a role.

I have to wait 15 minutes

Chris Farris: so it ends. If you pay , turn on a event, bridge [00:36:00] cha ching cha ching, but you gotta get a plan, right?

Damien Burks: But I think that's something that should be that. It's commonsensical, but you should have a lot. That should be free, right? You have to have a new service to be able to, Oh, now I have to create an event trigger for this particular API call so that it didn't trigger this thing and that thing.

Rich Mogull: As a vendor, I love it because when customers send us their events, The customer's paying to send us the advice. We don't pay anything to receive them, which might also be a problem.

Meg Ashby: As an AWS person, I wish there was more education of the community around more advanced or slightly off the golden path implementations of things.

I love being in Slack and chatting with y'all, but part of me just wishes I didn't have to be subscribed to the top of some specific, like LinkedIn posts to like actually learn about, Oh, I want to do this implementation. That's not mentioned anywhere in AWS docs. Support is I don't know, here's the AWS docs.

[00:37:00] That is something I would like to see more as a user.

Ashish Rajan: More actual use cases with implementation. Perhaps automation as well as how to get infrastructure as code for it.

Meg Ashby: Yeah, and even if it's this is not official, approved references. I get it, that's fine. But if it's only the perfect signed off way or nothing, that's where I leave unsatisfied.

Chris Farris: They need to empower the community to understand how we need to handle our side of shared responsibility and they need to empower the community to understand where the rough edges are on their side and accept the responsible disclosures that are coming from the community.

Patrick Sanders: There's an antagonistic relationship that the CSPs overall, not just AWS, have with researchers, who are trying to share information so that we can all be better. And that needs to stop. Let's be real. So yeah,

Rich Mogull: the problem, I'm not fully defending the CSPs here, but having been on multiple sides of this, is.

A lot of the research that comes out is from [00:38:00] vendors who want to get free marketing and headlines to sell their products. So some of the things that are reported, they're often all important and valuable. But like the reason Chris and I wrote this whole threat model is because we want to see that information.

But CISOs don't know that's not the problem, that the problem is access keys in GitHub. And so there's the muddling of the waters, and those pieces of it that can be difficult, so I will tend to err on the side of the researchers, and I want that work, and I want it published, and we know that vendors are trying to suppress that.

Not the vendor's research teams, but other providers try to suppress that and back in the corners and play legal games. And that shouldn't be done. They need to be better about that piece of it. But we also need to temper it because we also need the researchers to stop coming up with some overhyped, stupid, whatever name for their, but one like little thing that they found,

Chris Farris: it's like, [00:39:00] it's not important,

Rich Mogull: but we're done, we had blaster and we had heart bleed and can we just end it all and give them numbers at this point, instead of like these, Oh yeah.

Ashish Rajan: If you haven't heard of the whole CVE conversation, it CVE for cloud security vulnerabilities or misconfigurations and all of that. For people who are coming into the industry today, What's your advice to someone who's walking the path of cloud security sounds like a cool field. Where should they start?

Patrick Sanders: I would say this, community. It's that's what drives so much of this. And I learned so much from a lot of the people in this room and just so many people that are in the cloud security forum slack. And it's awesome. And people are so nice and so helpful and incredibly smart. Yeah.

And it's such a great resource.

Abdie Mohamed: One thing, if you're trying to get into this line of work, understand that there's so many resources out there, there's so many people giving advice across, social media platforms. You have to do your due diligence, do your research, and, sometimes turn down the noise a little bit.

You shouldn't listen [00:40:00] to everybody, because, if you listen to everybody you're not listening to anybody. And you can't make everybody happy, right? If you're new to this, I understand it can be difficult. Intimidating. Even now, I've been doing this for a minute and I still feel intimidating at times.

I would say definitely, be mindful of who you're listening to and you give advice and who you're following because there's a lot of advice out there, but not all advice is good advice.

Ashish Rajan: Yeah, because you do some mentorship thing as well, right? Yeah I'm mentor folks because I think it's, is there what else?

The reason I brought that up is because, do you feel getting a mentor is helpful for people and find the right kind of mentor yeah.

Abdie Mohamed: Yeah. So there's different types of mentors. Some mentors, they might be old school, they might not hit you up at all. And, it's on you to maintain that relationship as well.

So everybody's different, right? Yeah. But what I do recommend is finding a mentor that you can connect with, that you can relate to. I think it will be a game changer. It makes your career a lot easier. It makes life a lot easier. It's. The cool part about getting mentors is that, especially in this community, people want to help.

That's what I love about the security community, the tech community. People just want to help. I recommend definitely [00:41:00] get a mentor and do your due diligence. What you don't do is DM someone on LinkedIn and say, Be my mentor. I'm saying this from experience. I've done this and I've been left unread, people.

So don't write a, don't write an essay. Tell someone be my mentor on the first first message to somebody on a social media platform go outside like my friend here said, check in with the community, go outside, meet new people. That's the way to go.

Chris Farris: So I'm going to quote Werner here and say, just go build.

And to your point, it is fun to build something in AWS. It's reasonably inexpensive from a, cash out of pocket. Be careful . It gets a lot more expensive when you put your access keys in GitHub or leave SageMaker instance running over the weekend. But you can build and you will learn things from that building.

And that will as a security professional make you more empathetic to the builders that you want to then support. So the first project I [00:42:00] did in AWS was building a Minecraft server for my daughter that would spin up at 3pm when she got home from school and shut down at 8pm when it was her get off electronics time.

And that was an EC2 instance and a Lambda function to turn it on and off and messing around a little bit with, writing scripts to update Route 53 so that minecraft. room17. com went into the right IP address that was my first IaC project, something slightly practical. It cost me like five, seven bucks a month.

So just go build.

Ammar Alim: I think I'm going to build on top of what the foundation that you just got from Chris and Abdie because first who to follow. I would follow someone who was able to build something and sell it because the market is the ultimate judge.

Yeah.

Ammar Alim: Rich, anyone who's, able to commercialize cloud security.

That's someone you can see what they have and get, read a blog. Don't look at my Git, , don't look at my i'll click. So don't follow everyone. Don't waste your time.

Yeah.

So don't [00:43:00] be in the business of always consuming. =Now you have to go build. Yeah. Meaning build, making stuff like producing stuff, learn in public. Go get a domain, first name, last name, just put your notes there, the sooner you start the better. It doesn't have to be a perfect blog and pictures and formatted and grammar is correct. Just learn in public, leave it there, in five years you will be surprised with that.

Rich Mogull: Obviously support all of that because the community and the building was how I got started by experimenting.

I was forced to build some stuff for, we were actually building the training classes for the cloud security alliance, and it forced me to learn automation skills and stuff I'd never had to learn before. I have this thing cloud security lab a week that it's just an email newsletter, you can subscribe to it, and it starts, you have to have zero cloud knowledge and zero security knowledge, and the goal is to get you, teach you how to build a large scale enterprise deployment.

So about six months into it at this point, I plan to keep that going on. For as long as I can see,

Ammar Alim: I consume it, I can testify

Ashish Rajan: i spin up an EC2 instance sometimes [00:44:00]

Rich Mogull: gonna get to, Chris and I were talking about that. I gotta get it over to EC2. We haven't done that yet. But the other part is like your show, the people watching this, thank you.

The newsletters are good sources. You don't have to understand everything in them because some of them will talk about the biggest bombs and everything else. Yeah. But be a consumer of like different ideas and personalities and stuff. Can't read and subscribe and listen to everybody. And I would say use those more than Twitter or LinkedIn or Mastodon or whatever, because that's so noisy.

That might help you figure out who to look towards. You get in the cycle of just always trying to keep up with what I miss and what I miss and what I miss. When you're just getting into the field and learning, it's just about absorbing as much as you can and then figuring out which part of it's most interesting to you.

Is it IR? Is it building? Is it whatever.

Meg Ashby: Especially when I was first starting out, And there were definitely less services than there are even today, but really being aware of where you as an individual are starting. Like my first project was doing like config auto remediation before config auto remediation was formally [00:45:00] supported.

And then from there, built into the, okay what other rules could we add? So if you're coming maybe for more of a software background, focus then on What are the components that it would be to run? You know your code just on an EC2 when the network game to your database And then the classic exposing it to the internet if you chose to do that yeah and trying to focus on one area to start and dip your feet into instead of maybe like just jumping into the Ocean

Damien Burks: network as much as possible and ask a lot of questions The field itself is like really broad.

There's a lot of areas and avenues that you can specialize, find what works for you and what you're truly interested in, and then take a stab at it build a portfolio. If you feel that you want to pivot into something different, don't hesitate to do so because at the end of the day, it's your journey.

And I think that you have to be aware enough to understand that you will end up wearing multiple hats in your career as you matriculate through it. It's going to happen. And so it's just a matter of just accepting it. Building, build your [00:46:00] network, build your brand and ask as many questions as possible and pay it forward.

Always pay it forward.

I

Chris Farris: want to say one more thing on community, cause we didn't actually say it. fwd:cloudsec. We have a Slack community that we are all in. We have a annual, now twice a year, all over the globe conference that many of us are organizers, former speakers, future speakers at, and we always describe fwd:cloudsec as a graduate level.

Kind of conference compared to the undergraduate stuff that you would see at reinforced, but the slack is really where we can have these kinds of questions around. Did you see what happens when you commit eight access keys to a public GitHub repo and support comes back with eight different weird responses to that.

All of that are things that we can discuss in that community. And even if you're like, too nervous to contribute just watching the conversation happen to your point of learning in public. We're all learning in public in the Slack chat.

Damien Burks: My YouTube channel is DevSecBlueprint. [00:47:00] So essentially what I talk about mostly is cloud security in a generic sense and DevSecOps.

It's mostly my background. My specialty is helping developers become more secure and also developing and building and deploying, testing secure applications with cloud products and services. If you guys are interested in that content, definitely give me a follow on that. At Damien J. Burks and also my blog as well.

Ashish Rajan: One project that Shilpi and I have been running is called Cloud Security Bootcamp and it goes back to what you were saying earlier about implementation. So we've been running the podcast for almost five years now. Over time, we started getting questions about that. Hey, I want to do this specific thing.

Every time we would upload a video on Cloud Security Podcast for, hey, I did this thing, for whatever class I was teaching for, and it would just blow up. experience people to what you said. Some of us take that information for granted. But for everyone, it's oh my god, it's just gold. Can we get some more of this?

Whatever the things are. Like, so we separated created a separate YouTube channel for all of this. The reason I bring that whole Cloud Security Bootcamp thing is because, where do we stand on the whole, you mentioned graduate, [00:48:00] undergraduate. A lot of people are graduating today. They've all been told, Cloud is amazing.

It's on Amazon, Google, Microsoft. We have a great future ahead. Let's find something in cloud. If you skip the IT fundamentals and it jumps straight to cloud, I can't teach someone network even, and I'm being very conscious on that Cloud Security Bootcamp channel as well, that hey, I'm not teaching you fundamentals of networking that, how do you do servers talk to each other?

Chris Farris: You need IT in general to be good at cloud because. What is the cloud? The cloud is somebody else's computer. What does somebody else's computer run? It's running an operating system. You need to know the fundamentals of an operating system, what an environment variable is, because you have environment variables, whether they're in the hypervisor, which you don't see in the cloud, or they're in the EC2 instance, or they're in the container, or they're in the lambda, or they're in the code build, or they're in this other higher order service that takes it and executes code.

So you need some of those fundamentals. Do you need to have gone through and be as old and grizzled as I am on, having installed Linux on floppy disks? [00:49:00] No, but you need some of that. So yes, you should log into a Linux box and know how it works. If you've got a Mac, open terminal, understand what that means.

Abdie Mohamed: By learning fundamentals, it really gives you an appreciation for the cloud. Yeah. Of course. Yeah. For all these managers, you get an appreciation for it. You understand what's going on under the hood and think about it like this too, think about athletes. Athletes have to work on the fundamentals all the time, if you look at basketball players, sorry.

Kobe Bryant went to the net every day. Kobe Bryant, what was he practicing? He's always practicing layups. Yeah. Practicing basic moves, in the game, he's doing all these crazy moves in the game, but that's because the foundation was laid there. I think learning the fundamentals is very valuable.

Meg Ashby: But I would say I don't want that to stop. Yeah. Don't let that stop you. From my personal experience, I was one of the random people.

People who like, accidentally landed a cloud security job out of college. Oh, we have one! Good job. It was an accident, it wasn't even on [00:50:00] purpose. They said find here and I find it. What did you think you were applying for? At the time, in short, I joined a big enterprise bank. And when I signed the job offer, it was not a cloud security team.

And by the time I got there, it was a cloud security team. So I would say you can learn it a little bit as you go, but do know it will hamper you, especially like not knowing those fundamentals and things. When we're looking at the compute services, you can get away with it, I think, a bit more with Lambda and those other abstracted. But I would say if you're doing Kubernetes, you gotta know it at that point.

Patrick Sanders: We're talking about this in the context of graduating and going into a job, but it doesn't need to be that either. The background that you can get and the experience that you have from literally any other job can be applied to cloud security, like literally everything

Chris Farris: and don't let imposter syndrome. Oh, I don't know as much about this as somebody else, or I [00:51:00] don't know how a packet gets from point A to point B. Don't worry about that. There is no compression algorithm for experience. So you're going to learn as you go.

That is part of all of our journeys here is scratching our heads and trying to figure out and then things will change. You'll suddenly go from a nit D to system D and you'll be like, Oh man, but don't let that slow you down. Leverage what skills you have. They don't have to be completely technical to, put your foot in

the door.

I

Damien Burks: want to point out like you definitely want to make sure that not only do you work on your technical skills, but your interpersonal skills as well. All right. Thank you. Oh my God. Patience. It's the number one skill you have to have in doing anything in the cloud, especially in the cloud security engineering, because it will be testing, you will be banging your head against the wall asking yourself, what the hell am I doing?

It's like day one every day sometimes, so you just gotta remember that, it comes with the territory, so just make sure you have patience and just understand that you're not the only person [00:52:00] who may feel that way. Yeah. And that's where community helps. Yes.

Ashish Rajan: I understand. Community baby. Alright, final question.

So if you were not in cloud security, or technical person at all, what would you be doing?

Damien Burks: Honestly, man, before all of this, I wanted to be a mechanic. I wanted to work with cars. Oh! That makes so much sense. It's either cars, or I wanted to be an FBI. Those are my two things.

Ashish Rajan: The FBI. Oh wow, okay.

You're flipping the badge at people. FBI, get down on the floor.

Damien Burks: Watch bad boys, baby.

Meg Ashby: This might be a little bit of a niche answer, but I think I would definitely thrive as one of those people that worked at airports, like inspecting overseas package import for drugs or For other illegal imports specifically packages.

I don't really want to talk to people. Monitoring packages.

Patrick Sanders: So cloud security. Someone would be really good at software bill of material, [00:53:00] right?

Rich Mogull: SBOM

Ashish Rajan: thank you for sharing that.

Rich Mogull: Don't say SBOM in an airport. Not those two words together. Paramedic in a national park. Oh wow. That's my retirement plan.

I'm gonna be seasonal. My wife's gonna be an interpretive ranger. I'll be a rescue slash paramedic ranger.

Chris Farris: And we know for a fact that people every year will go and try and pet the buffaloes in Yellowstone

Rich Mogull: exactly. Or they'll take selfies on the edge of whatever. .

Ammar Alim: So I like to be the, in the back country, rugged

I like it there. And the only thing I thought about was, like, taking people and charging them for that. Hey, I'll take you to over there, Washington State, and I have friends who do that for a living now. Alright, hook me up. Amazing. See, how can I do that? I do that with friends, but how can I, do it for a living?

That would be I'm glad we were connect.. Now you can connect and find out

Chris Farris: if I had to pick a different career right now, I'd be a travel blogger. Some people have a face [00:54:00] for radio. I have a voice for blogging. So it would be a travel blogger.

Abdie Mohamed: I want to become an economist.

That was my original plan. Economist? Oh, wow, good. Yeah, because I just love studying how the world works. Yeah, the way the world works, the way societies work, the way we trade. The history of trade, the history of commerce, the history of money. That stuff's interesting to me. And then I found out I need to get my PhD to become an economist.

So I didn't get that. Yeah, if I wasn't doing this, I'd probably become an economist.

Ashish Rajan: Oh, that's pretty awesome.

Patrick Sanders: Either running a bakery or a coffee shop. Oh! Because I want to just like, Really spend some time with some dough.

Ammar Alim: I'm sorry, but you look like you can make a good shot.

Ashish Rajan: You have to look for it, yeah.

I'll take that. It's very trustworthy. Funny thing is, my time plan is the same as well. I would love to open a coffee shop. I've been actually scouting based in London already. I appreciate all of you joining us. And sharing all that as well. And I look forward to when this comes out and the internet [00:55:00] roars.

But, thank you everyone for coming in.

Abdie Mohamed: It's been a pleasure.

Ashish Rajan: I look forward to this episode, people. I look forward to this episode getting

Abdie Mohamed: on the internet. I'm sending this to my mom.

Ashish Rajan: Awesome. so much. Good job. And that's the episode, people. Thank you forr listening or watching this episode of Cloud Security Podcast.

We have been running for the past five years, so I'm sure we haven't covered everything cloud security yet. And if there's a particular cloud security topic that we can cover for you in an interview format on Cloud Security Podcast or make a training video on tutorials on Cloud Security Bootcamp, definitely reach out to us on info at cloudsecuritypodcast.

tv. By the way, if you're interested in AI and cybersecurity, as many cybersecurity leaders are, you might be interested in our sister podcast called AI cybersecurity podcast, which I run with former CSO of Robin Hood, Caleb Seamer, where we talk about everything AI and cybersecurity, how can organizations deal with cybersecurity on AI systems, AI platforms, whatever AI has to bring next as an [00:56:00] evolution of chat, GPT, and everything else continues.

If you have any other suggestions, definitely drop them on info at Cloud Security Podcasts or TV. I'll drop them in the description and the show notes as well. So you can reach out to us easily. Otherwise, I will see you in the next episode. Peace.

‍