Screaming in the Cloud - Solving for Cloud Security at Scale with Chris Farris

Episode Date: January 24, 2023

About Chris Chris Farris has been in the IT field since 1994 primarily focused on Linux, networking, and security. For the last 8 years, he has focused on public-cloud and public-cloud security. He has built and evolved multiple cloud security programs for major media companies, focusing on enabling the broader security team’s objectives of secure design, incident response and vulnerability management. He has developed cloud security standards and baselines to provide risk-based guidance to development and operations teams. As a practitioner, he’s architected and implemented multiple serverless and traditional cloud applications focused on deployment, security, operations, and financial modeling.Chris now does cloud security research for Turbot and evangelizes for the open source tool Steampipe. He is one if the organizers of the fwd:cloudsec conference (https://fwdcloudsec.org) and has given multiple presentations at AWS conferences and BSides events.When not building things with AWS’s building blocks, he enjoys building Legos with his kid and figuring out what interesting part of the globe to travel to next. He opines on security and technology on Twitter and his website https://www.chrisfarris.comLinks Referenced:Turbot: https://turbot.com/fwd:cloudsec: https://fwdcloudsec.org/Steampipe: https://steampipe.io/Steampipe block: https://steampipe.io/blog

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. Tailscale SSH is a new and arguably better way to SSH. Once you've enabled Tailscale SSH on your server and user devices,

Tailscale takes care of the rest, so you don't need to manage, rotate, or distribute new SSH keys every time someone on your team leaves. Pretty cool, right? Tailscale gives each device in your network a node key to connect to your VPN, then uses that same key for SSH authorization and encryption. So basically you're SSHing the same way you're already managing your network. So what's the benefit? Well, built-in key rotation,

the ability to manage permissions as code, connectivity between any two devices, and reduced latency. You can even ask users to re-authenticate SSH connections for that extra bit of security to keep the compliance folks happy. Try Tailscale now. It's free forever for personal use.

This episode is sponsored in part by our friends at Logicworks. Getting to the cloud is challenging enough for many places, especially maintaining security, resiliency, cost control, agility, etc., etc., etc. Things break, configurations drift, technology advances, and organizations, frankly, need to evolve. How can you get to the cloud faster and ensure you have the right team in place to maintain success over time? Day two matters. Work with a partner who gets it. Logicworks combines the cloud expertise and platform automation to customize solutions to meet your unique requirements. Get started by chatting with a cloud specialist today at snark.cloud slash logicworks.

That's snark.cloud slash logicworks. And my thanks to them for sponsoring this ridiculous podcast. Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today is someone that I have been meaning to invite slash drag onto this show for a number of years. We first met at Reinforce the first year that they had such a thing, Amazon Security Conference for Cloud, as is Amazon's tradition, named after an email subject line. Chris Farris is a cloud security nerd at Turbot. He's also one of the organizers for

Forward CloudSec, another security conference named after an email subject line with a lot more self-awareness than any of Amazon stuff. Chris, thank you for joining me. Oh, thank you for dragging me on. You can look on my hair now. Wonderful. Wonderful. That's why we're all having the thinning hair going on. People just use it to drag us to and fro, it seems. So you've been doing something that I'm only going to describe as weird lately because your background, not that dissimilar from mine, is as a practitioner.

You've been heavily involved in the security space for a while. And lately, I keep seeing an awful lot of things with your name on them getting sucked up by the giant app surveillance apparatus deployed to the internet looking for basically any mention of AWS that I wind up using to write my newsletter and feed the content gristmill every year. What are you doing and how do you get there? So what am I doing right now is I'm in marketing. It's kind of a, you know, oops, I'm sorry I did that. Oh, the running gag is you work in DevRel. That means, oh, you're in marketing, but they're scared to tell you that. You're self-aware. Good for you. I'm willing to address that I'm in marketing now. And I've been

a cloud practitioner since probably 2014, cloud security since about 2017, and then just decided the problem that we have in the cloud security community is a lot of us are just kind of sitting in a corner in our companies and solving problems for our companies, but we're not solving the problems at scale. So I wanted a job that would allow me to reach a broader audience and help a broader audience. Where I see cloud security having, or cloud in general falling down is, Amazon makes it really hard for you to do your side of shared responsibility. And so we need to be out there helping customers understand what they need to be doing. So I am now at a company called Turbot, and we're really trying to promote cloud security. One of the first promoted guest episodes

of this show was David Boeke, your CTO. And one of the things that I regret is that I've sort of lost track of Turbot over the past few years because, you know, one or two things might have been going on during that timeline as I look back at having kids in the middle of a pandemic and the deadly plague or the land, and suddenly every conversation takes place over Zoom, which is like, oh good, it's like a happy hour, only instead now it's just like a conference call for work. It's like conference calls. The drinking game is never the great direction to go in. But it seems the world is recovering. We're going to be able to spend some time together at reInvent by all accounts that I'm actively looking forward to. As of this recording, you're relatively new to Turbot. And I figured out that you were going

there because, once again, content hits my filters. You wrote a fascinating blog post that hits on an interest of mine that I don't usually talk about much because it's off-putting to some folk, and these days I don't want to get yelled at more than I have to, about the experience of traveling, I believe it's to an all-hands, on the other side of the world. Yep. So my first day on the job at Turbot, I was landing in Kuala Lumpur, Malaysia, having left the United States 24 hours or was it 48? That's hard to tell when you go to the other side of the planet and the time zones have all shifted. And then having left my prior company a day before that. But yeah, so Turbot traditionally has an annual event where we all get together in person.

We're a completely remote company, but once a year we all get together in person in our integrate event. And so that was my first day on the job. And then it was basically two weeks of reasonably intense hackathons, building out a lot of stuff that hopefully will show up open source shortly and then yeah meeting all of my co-workers and that was nice you've always had a focus through all the time that i've known you and all the public content that you've put out there that has come across my desk that seems to center around security it's sort of an area that I give a nod to more often than I would like on some level, but that seems to be your bread and butter. Your focus seems to be almost overwhelmingly on, I would call it AWS security. Is that fair to say, or is that a mischaracterization of how you view

it slash what you actually do? Because again, we have these parasocial relationships with voices on the internet and it's like, oh yeah, I know all about that person. Yeah, you've met them once and all, you know, and that is what they put on Twitter. You follow me on Twitter. Yeah. I would argue that yes, a lot of what I do is AWS related security because in the past, a lot of what I've been responsible for is cloud security and AWS. But I've always worked for companies that were multi-cloud. It's just that 90% of everything was Amazon. And so therefore, 90% of my time, 90% of my problems, 90% of my risk was all in AWS.

I've been trying to break out of that. I've been trying to understand the other clouds. One of the nice aspects of this role and working on Steam Pipe is I am now experimenting with other clouds. The whole goal here is to be able to scale our ability as an industry and as security practitioners to support multiple clouds. Because whether we want to or not, we've got it.

And so even though 90% of my spend, 90% of my resources, 90% of my applications may be in AWS, that 10% that I'm ignoring is probably more than 10% of my risk. And we really do need to understand and support major clouds equally. One post you had recently that I find myself in wholehearted agreement with is on the adoption of tail scale in the enterprise. I use it for all of my personal nonsense and it is transformative.

I like the idea of what that portends for a multi-cloud or poly-cloud, whatever the hell we're calling it this week, sort of architectures where historically one of the biggest problems in getting two clouds to speak to one another or manage them in an intelligent way is the security models are different. The user identity stuff is different as well. And the network stuff has always been nightmarish. Well, with Tailscale, you don't have to worry about that in the same way at all. You can more or less ignore it, turn on host-based firewalls for everything and just allow Tailscale. And suddenly, okay,

I don't really have to think about this in the same way. Yeah. And you get the micro-segmentation out of it too, which is really nice. I will agree that I had not looked at Tailscale until I was asked to look at Tailscale. And then it was just like, oh, I am completely redoing my home network on that. But looking at it, it's going to scare some old school network engineers. It's going to impact their livelihoods and that's going to make them very defensive. And so what I wanted to do in that post was kind of address as a practitioner, if I was looking at this with an enterprise lens, what are the concerns you would have on deploying tail scale in your environment? A lot of those were, you know, around user management. I think the big one that is, it's a new thing in enterprise security, but kind of this host profiling, which is, hey, before I let your laptop on the network,

I'm going to go make sure that you have antivirus and some kind of EDR, XDR, blah, DR agents so that we you know, we have a reasonable thing that you're not going to just go and drop not Petya on the network. And next thing you know, we're Maersk. Tailscale, that's going to be their biggest thing that they're going to have to figure out is how do they work with some of these enterprise concerns and things along those lines. But I think it's an excellent technology. It was super easy to set up and the ability to fine tune and micro segment is great. Wildly.

So they occasionally sponsor my nonsense. I have no earthly idea whether this episode is one of them because we have an editorial firewall. They're not saying it is any of this, but I'm like, and this is brought to you by whatever. Yeah. That's the sponsored ad part. This is just, I'm we have an editorial firewall. They're not paying me to say any of this, but I'm like, and this is brought to you by whatever. Yeah, that's the sponsored ad part. This is just, I'm in love with the product.

One of the most annoying things about it to me is that I haven't found a reason to give them money yet because their free tier for my personal stuff is very comfortably sized. And I don't have a traditional enterprise network or anything like that that people would benefit from over here. One area in cloud security that I think I have potentially been misunderstood around, so I want to take at least this opportunity to clear the air on it a little bit,

has been that by all accounts, I've spent the last few months or so just absolutely beating the crap out of Azure. Before I wind up adding a little nuance and context to that, I'd love to get your take on what, by all accounts, has been a pretty disastrous year and a half for Azure security. I think it's been a disastrous year and a half for Azure security. That was something of a leading question, wasn't it? Yeah, no, I mean, it is. That was something of a leading again, or hopefully we're hitting the peak and not just starting the uptick. A lot of what Azure has built is stuff that they already had, commercial off-the-shelf software.

They wrapped multi-tenancy around it, gave it a new SKU under the Azure name, and called it cloud. So am I super surprised that somebody figured out how to leverage a Jupyter notebook to find the backend credentials, to drop the firewall tables, to go find the next guy over Cosmo DB? No, I'm not. I find their failures to be less egregious on a technical basis, because let's face it, let's be very clear here. This stuff is hard. I am not pretending for even a slight second that I'm a better security engineer than the very capable, very competent people who work there.

This stuff is incredibly hard. And I'm not- And very well-funded people. Oh, absolutely. They make more than I do, presumably, but it's one of those areas where I'm not sitting here trying to dunk on them, their work, their efforts, etc. And I don't do a good enough job of clarifying that. I'm hard-pressed to imagine a scenario where they would not have much more transparent communications. They might very well trot out a number of their execs to go on a tour to wind up talking about these things and what they're doing systemically to change it. Because six of these in, it's like, okay, this is now a cultural problem.

It's not one rando engineer wandering around the company screwing things up on a rotational basis. It's, what are you going to do? It's unlikely that firing Steven is going to be your fix for these things. So that is part of it. And then most recently, they wound up having a blog post on the MSRC,

the Microsoft Security Resource Centers, I believe that acronym, the MRFs, whatever. And it sounds like a virus you pick up in a hospital. But the problem that I had with it is that they spent most of that being overly defensive and dunking on SOC radar.

The vulnerability researcher who found this and reported it to them. And they had all kinds of quibbles with how it was done, what they did with it, et cetera, et cetera. It's, excuse me, you're the ones that left customer data sitting out there in the Azure equivalent of an S3 bucket. And you're calling ones that left customer data sitting out there in the Azure equivalent S3 bucket. And you're calling other people out for basically doing your job for you.

Excuse me. But it wasn't sensitive customer data. It was only the contract information. So therefore, it was OK. Yeah, if I put my contract information out there and try and claim it's not sensitive information, my clients will laugh and laugh as they sue me into the Stone Age. Well, clearly you don't have the same level of click-through terms that Microsoft is able to negotiate because, you know. It's awful as well. It doesn't even work

because, oh, it's okay. I lost some of your data, but that's okay because it wasn't particularly sensitive. Isn't that kind of up to you? Yes. And if, hey, I'm actually a big AWS shop and then I'm looking at Azure and I've got my negotiations in there and Amazon gets wind that I'm negotiating with Azure, that's not going to do well for me and my business. So no, this kind of material is incredibly sensitive. And that was an incredibly tone-deaf response on their part. But, you know, to some extent, it was more of a response than we've seen from some of the other Azure multi-tenancy breakdowns. Yeah, at least they actually said something. I mean, there is that. It's just, it's wild to me.

And again, I say this as an Azure customer myself, their computer vision API is basically just this side of magic as best I can tell. And none of the other providers have anything like it. That's what I want. But it almost feels like that service is under NDA because no one talks about it when they're using this service. I did a whole blog post singing its praises and no one from that team reached out to me to say, hey, glad you liked it. Not that they owe me anything, but at the same time, it's incredible. Why am I getting shut out? It's like, does this company just have an entire policy of not saying anything ever to anyone at any time? It seems it. So a long time ago, I came to this realization that if you look at, even if you just look at the terminology of the three providers, Amazon has accounts.

Why does Amazon have AWS accounts? Because they're a retail company, and that's what you signed up with to buy your underwear. Google has projects because they were, I guess, a developer first thing, and that was how they thought about it. Oh, you're going to go build something. Here's your project. What does Microsoft have? Microsoft Azure subscriptions, because they are still about the corporate enterprise IT model of, it's really about how much we're charging you, not really about what you're getting. So given that you're not a big enterprise IT customer,

you don't, I presume, do lots and lots of golfing at expensive golf resorts. You're probably not fitting their demographic. You're absolutely not. And that's wild to me. And yet here we are. Now, what's scary is they are doing so many interesting things with artificial intelligence that if their multi-tenancy boundaries are as bad as we're starting to see, then what else is out there?

And the more and more we as carbon-based life forms are relying on Microsoft and other cloud providers to build AI, that's kind of a scary thing. Go watch Satya's keynote at Microsoft Ignite, and he's showing you all sorts of ways that AI is going to start replacing the gig economy. You know, it's not just Tesla and self-driving cars at this point. DALI is going to replace the independent graphics designer. They've got things coming out in their office suite that are going to replace the mom and pop marketing shops that are generating menus and doing marketing plans for your local

restaurants or whatever. There's a whole slew of things where they're really trying to replace people. That is a wild thing to me. And part of the problem I have in covering AWS is that I have to differentiate in a bunch of different ways between AWS and its Amazon corporate parent. And they have that problem too internally. Part of the challenge they have in many cases is that perks you give to employees have to scale to one and a half million people, many of them in fulfillment center warehouse things. And that is a different type of problem than a company like, for example, Google, where most of their employees tend to be in office job style environments. That's a weird thing. And I don't know how to even start conceptualizing things operating at that scale. Everything that they do is definitionally a very hard problem when you have to make it scale to that point. What all of the hyperscale cloud providers do is, from where I sit, complete freaking magic. The fact that it works as well as it does is nothing short of a modern-day miracle. Yeah, and it is more than just throwing

hardware at the problem, which is my on-prem solution to most of the things. Oh, hey, we need higher availability. Okay, we're going to buy two of everything. We called it the Noah's Ark model. We have an A-side and a B-side. And oh, you know what, just in case, we're going to buy some extra capacity and put it in a different city so that we can just fail from our primary city to our secondary city. That doesn't work at the cloud provider scale. And really, we haven't seen a major cloud outage, I mean, like a bad one, in quite a while. This episode is sponsored in part by Honeycomb. When production is running slow, it's hard to know where problems originate. Is it your application code, users, or the underlying systems? I've got five bucks on DNS, personally. Why scroll through endless dashboards while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You

should care more about one of those than the other. Which one is up to you? Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business, production. With Honeycomb, you guess less and know more. Try it for free at honeycomb.io slash screaming in the cloud. Observability. It's more than just hipster monitoring. The outages are always fascinating just from the way that they are reported in the mainstream media.

And again, this is hard. I get it. I am not here to crap on journalists. They, for some ungodly, unknowable reason, have decided not to spend their entire career focusing on the nuances of one very specific, very deep industry. I don't know why, but as a result, they wind up getting a lot of their baseline facts wrong about these things. And that's fair. I'm not here to necessarily act as an Amazon spokesperson when these things happen. They have an awful lot of very well-paid

people who can do that. But it is interesting just watching the blowback and the reaction of whenever there's an outage, the conversation is never, does Amazon or Azure or Google suck? It's, does cloud suck as a whole? That's part of the reason I care so much about Azure getting their act together. If it were just torpedoing Microsoft's reputation, then, well, that's sad, but okay. But it extends far beyond that to a point where it's almost where the enterprise groundhog sees the shadow of a data breach, and then we get six more years of data center build outs instead of moving things to a cloud. I spent too many years working in data centers, and I have the scars from the cage knots and

crimping patch cables frantically in the middle of the night to prove it. I am thrilled at the fact that I don't believe I will ever again have to frantically drive across town in the middle of the night to replace a hard drive before the rest of the array degrades. Cloud has solved those problems beautifully. I don't want to go back to the dark ages. Yeah, and I think that there's a general potential that we could start seeing this big push towards going back on-prem for effectively sovereign data reasons. Whether it's this country has said you cannot store your data about our citizens outside of our borders. And either they're doing that because they do not trust the US, Silicon Valley privacy or whatever,

or because if it's outside of our borders, then our secret police agents can't come knocking on the door at two in the morning to go find out what some dissidents viewing habits might've been. I see Sovereign Cloud as this thing that may be a backstep from this ubiquitous thing that we have right now in Amazon, Azure, and Google. And so as we start getting to the point in the history books

where we start seeing maps with lots of flags, I think we're going to start seeing a bifurcation of cloud as just a whole thing. We see it already right now. The AWS China partition is not owned by Amazon. It is not run by Amazon. It is not controlled by Amazon. It is controlled by the communist government of China. And nobody's doing business in Russia right now. But if they had not done what they had done earlier this year, we might very well see somebody spinning up a cloud provider that is completely controlled by and in the Russian government. Well, yes and no, but I want to challenge that assessment for a second, because I've had conversations with a number of folks about this, where people say, okay, great, is the alt-right, for example, going to have better options now that there might be a cloud provider spinning up there?

Or, well, okay, what about a new cloud provider challenge the dominance of the big three? And there are all these edge cases, either geopolitically or politically, based upon or folks wanting to wind up approaching from a particular angle. But if we were hired to build out an MVP of a hyperscale cloud provider, the budget for that MVP would look like, what, $100 billion at this point to get started and just get up to a point of critical mass before you could actually see if this thing has legs? And we'd probably burn through almost all of that before doing a single dime in revenue. Right. And then you're doing that in small markets. Outside of the China partition, these are not massively large markets. I think Oracle is going down an interesting path with its idea of dedicated cloud and Oracle Alloy and software. I like a lot of what Oracle's doing. And if younger me heard me say that,

I don't know how hard I'd hit myself. But here we are. Their free tier for Oracle Cloud is amazing. Their data transfer prices are great. And their entire approach of, we'll build an entire feature-complete region in your facility and charge you what, from what I can tell, is a very reasonable amount of money, works. And it is feature-complete. Not, well, here are the three services that we're going to put in here and everything else is, well, it's just sort of a toehold there so you can start migrating it into our big cloud. No, they're doing it right from that perspective. The biggest problem they've got is the word Oracle at the front and their, I would say, borderline addiction to big E enterprise markets. I think the future of cloud looks a lot more like cloud native companies being founded

because those big enterprises are starting to describe themselves in similar terminology. And as we've seen in the developer ecosystem, as go startups, so do big companies a few years later. Walk around any big company that's undergoing a digital transformation, you'll see a lot more Macs on desktops, for example. You'll see CICD processes in place, as opposed to, well, oh, you want something new? It's going to be eight weeks to get a server rack downstairs, and accounting is going to have 18 pages of forms for you to fill out. No, it's click the button. Don't forget the six months of just getting the financial CapEx approvals.

Exactly. You have to go through the finance thing before you even get to start talking to techies about when you get your server. I think Oracle is in an interesting place, though, because it is embracing the fact that it is number four. And so therefore it's like, we are going to work with AWS. We are going to work with Azure. We have our database can run in AWS or it can run in our cloud. We can

interconnect directly, natively, seamlessly with Azure. If I were building a consumer-based thing and I was moving into one of these markets where one of these governments was demanding something like a sovereign cloud, Oracle's a great place to go and throw, okay, all of our front-end consumer whatever is all going to sit in AWS because that's what we do for all other countries.

For this one country, we're just going to go in AWS because that's what we do for all other countries. For this one country, we're just going to go and build this thing in Oracle and we're going to leverage Oracle Alloy or whatever. And now suddenly, okay, their data is in their country and it's subject to their laws, but I don't have to re-architect to go into one of these little countries with tin horn dictators. It's the way to do multi-cloud right, from my perspective.

I'll use a component service in a different cloud. I'm under no illusions, though, in doing that, that I'm increasing my resiliency. I'm not removing single points of failure. I'm adding them. And I make that trade-off on a case-by-case basis, knowingly. But there is a case for some workloads, probably not yours, if you're listening to this, assume not, but when you have more context, maybe so, where, okay, we need to be across multiple providers for a variety of strategic or contextual reasons

for this workload. That does not mean everything you build needs to be able to do that. It means you're going to make trade-offs for that workload and understanding the boundaries of where that starts and where that stops is going to be important. That is not the worst idea in the world for a given appropriate workload that you can optimize stuff into a container and then can run more or less anywhere that can take a container. But that is also not the majority of most people's workloads. Yeah, and I think what that comes back to from the security practitioner standpoint is you have to support not just your primary cloud,

your favorite cloud, the one you know, you have to support any cloud. And whether that's, you know, hey, congratulations, your developers want to use Tailscale because it bypasses a ton of complexity in getting these remote island VPCs from this recent acquisition integrated into your network, or because you're going into a new market and you have to support Oracle Cloud in Saudi Arabia, then you as a practitioner have to kind of support any cloud.

And so one of the reasons that I've joined and I'm working on it and so excited about Steam Pipe is it kind of does give you that. It is a uniform interface to not just AWS, Azure and Google, but all sorts of clouds, whether it's GitHub or Oracle or Tailscale. So that's kind of the message I have for security practitioners at this point is I tried, I fought, I screamed and yelled and ranted

on Twitter against doing multi-cloud. But at the end of the day, we were still multi-cloud. The way that I see these things evolving is that, yeah, as a practitioner, we're increasingly having to work across multiple providers, but not to a stupendous depth. That's the intimidating thing that scares the hell out of people. I still remember my first time with the AWS console being so overwhelmed with the number of services, and there were 12. Now, there are hundreds, and I still feel that same sense of being overwhelmed. But I also have the context now to realize that over half of all customer spend globally is on EC2. That's one service.

Yes, you need like five more to get it to work, but okay. And once you go through learning that to get started, and there's a lot of moving parts around it, like, oh God, I have to do this for every service? No, take Route 53, my favorite database, but most people use it as a DNS service. You can go start to finish on basically everything that service does that a human being is going to use in less than four hours, and then you're more or less ready to go. Everything is not the hairy beast that is EC2, and most of those services are not for you. Whoever you are, whatever you do, most AWS services are not for you. Full stop. Yes and no. I mean, as a security practitioner, you need to know what your developers are doing. And I haven't worked in large organizations with lots of things. And I would joke that, oh, yeah, I'm sure we're using every service but IoT. And

then I go and I look at our bill and I was like, oh, why are we dropping that much on IoT? Oh, because they wanted to use the Managed MQTT service. Ah, I start with the bill because the bill is the source of truth. Yes, they wanted to use the Managed MQTT service. Okay, great. So we're now in IoT. But how many of those things have resource policies?

How many of those things can be made public? And how many of those things are your CSPM actually checking for and telling you that, hey, a developer has gone out somewhere and made this SageMaker notebook public or this MQTT topic public. And so that's where you need to have that level of depth, and then you've got to have that level of depth in each cloud. To some extent, if the cloud is just the core basic VMs, object storage,

maybe some networking and a managed relational database, super simple to understand what all you need to do to build a baseline to secure that. As soon as you start adding in all of the fancy services that AWS has. Migrating your step functions workflow to other cloud is going to be a living goddamn nightmare. Migrating something that you stuff into a container and run on EC2 or Fargate is probably going to be a lot simpler. But there are always nuances. But the security profile of a step function is significantly different. So, you know, there's not much you can do there wrong yet.

You say that now, but wait for their next security breach, and then we start calling them stumble functions instead. Yeah, I say that. And the next thing, you know, we're going to have something like Lambda UR show up, and I'm just going to be able to put my step function on the internet unauthenticated because, you know, that's what Amazon does. They innovate, but they don't necessarily warn security practitioners ahead of their innovation that, hey, we're about to release this thing. You might want to prepare for it and adjust your baselines or talk to your developers or here's a service control policy that you can drop in place to suppress it for a little bit. No, it's like, hey, these things are there. And by the time

you see the tweets or read the documentation, you've got some developer who's put it in production somewhere. And then it becomes a lot more difficult for you as a security practitioner to put the brakes on it. I really want to thank you for spending so much time talking to me. If people want to learn more and follow your exploits, as they should, where can they find you? They can find me at steampipe.io slash blog. That is where all of my latest rants, raves, research, and how-tos show up. And we will, of course, put a link to that in the show notes. Thank you so much for being so

generous with your time. I appreciate it. Perfect. Thank you. You have a good one. Chris Farris, cloud security nerd at Turbot. I'm cloud economist, Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast,

please leave a five-star review on your podcast platform of choice, along with an angry, insulting comment. And be sure to mention exactly which Azure communications team you work on. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point.

Visit duckbillgroup.com to get started. this has been a humble pod production stay humble