Screaming in the Cloud - Commanding the Council of the Lords of Thought with Anna Belak

Episode Date: March 1, 2022

About AnnaAnna has nearly ten years of experience researching and advising organizations on cloud adoption with a focus on security best practices. As a Gartner Analyst, Anna spent six years helping more than 500 enterprises with vulnerability management, security monitoring, and DevSecOps initiatives. Anna's research and talks have been used to transform organizations' IT strategies and her research agenda helped to shape markets. Anna is the Director of Thought Leadership at Sysdig, using her deep understanding of the security industry to help IT professionals succeed in their cloud-native journey.Anna holds a PhD in Materials Engineering from the University of Michigan, where she developed computational methods to study solar cells and rechargeable batteries.How do I adapt my security practices for the cloud-native world?How do I select and deploy appropriate tools and processes to address business needs?How do I make sense of new technology trends like threat deception, machine learning, and containers?Links:Sysdig: https://sysdig.com/“2022 Cloud-Native Security and Usage Report”: https://sysdig.com/2022-cloud-native-security-and-usage-report/Twitter: https://twitter.com/aabelakLinkedIn: https://www.linkedin.com/in/aabelak/Email: [e-mail]

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. Today's episode is brought to you in part by our friends at Minio, the high-performance Kubernetes native object store that's built for the multi-cloud,

creating a consistent data storage layer for your public cloud instances, your private cloud instances, and even your edge instances, depending upon what the heck you're defining those as, which depends probably on where you work. It's getting that unified is one of the greatest challenges facing developers and architects today. It requires S3 compatibility, enterprise-grade security and resiliency, the speed to run any workload, and the footprint to run anywhere. And that's exactly what Minio offers. With superb read speeds in excess of 360 gigs and a 100 megabyte binary that doesn't eat all the data you've got on the system, it's exactly what you've been looking for. Check it out today at min.io slash download and see for yourself. That's min.io slash download, and be sure to tell them that I sent you. This episode is sponsored by our friends

at Oracle HeatWave, a new high-performance query accelerator for the Oracle MySQL database service, although I insist on calling it MySquirrel. While MySquirrel has long been the world's most popular open-source database, shifting from transacting to analytics required way too much overhead and, you know, work. With HeatWave, you can run your OLAP and OLTP, don't ask me to pronounce those acronyms ever again, workloads directly from your MySquirrel database and eliminate the time-consuming data movement and integration work, while also performing 1,100 times faster than Amazon Aurora and two and a half times faster than Amazon Redshift at a third the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense. Welcome to Screaming in the Cloud, I'm Corey Quinn. Once upon a time, I went to a conference talk at basically a user meetup.

This was in the before times, when that wasn't quite as much of a deadly risk because of a pandemic, and mostly a deadly risk due to me shooting my mouth off when it wasn't particularly appreciated. At that talk, I wound up seeing a new open-source project that was presented to me, and it was called Sysdig. I wasn't quite sure on what it did at the time, and I didn't know what it would be turning into. But here we are now, what is it, five years later? Well, it's turned into something rather interesting. This is a promoted episode brought to us by our friends at Sysdig. And my guest today is their Director of Thought Leadership,

Anna Bellick. Anna, thank you for joining me. Hi, Corey. I'm very happy to be here. I'm a big fan. Oh, dear. So let's start at the beginning. Well, we'll start with the title, Director of Thought Leadership. That is a lofty title. It sounds like you sit on the Council of the Lords of Thought somewhere. Where does your job start and stop? I command the Council of the Lords of Thought, actually. Supply chain issues mean the robe wasn't available. I get it. I get it. There is a robe. I'm just not wearing it right now. So the shortest way to describe the role is probably something that reports into engineering, interestingly, and deals with product and marketing in a way that is half evangelism and half product strategy. I just didn't feel like being called any of those other things. So they were like,

director of thought leadership you are. And I was like, that sounds awesome. You know, it's one of those titles that people generally don't see a whole lot of. So it's, if nothing else, I always liked those job titles that cause people to sit up and take notice, as opposed to something that just people fall asleep by the time you get halfway through it it because it's the law of a promotion. People give you additional adjectives in your title and we're going to go with it. So before you wound up at Sysdig, you were at Gartner for a number of years. That's right. I spent about six years at Gartner and there half the time I covered containers, Kubernetes, and DevOps from an infrastructure perspective. And half the time I spent covering security operations, actually, not specifically with respect to containers or cloud, but broadly. And so my favorite thing is security operations as it relates to containers and cloud-aided workloads, which is kind of how I ended up here.

I wouldn't call that my favorite thing. It's certainly something that is near and dear to the top of mind, but that's not because I like it. Let's put it that way. It's one of those areas where getting it wrong is catastrophic. Back in 2017, when I went to that meetup in San Francisco, Sysdig seemed really interesting to me because it looked like it tied together a whole bunch of different diagnostic tools. LSOF, S-Trace, and the rest. Honestly, and I mean no slight to the folks who built out this particular tool, it felt like D-Trace, only it understood the value of being accessible to its users without basically getting a doctorate in something. I liked the idea,

and it felt like it was very much aimed at an in-depth performance analysis story or an observability play. But today, it seems that you folks have instead gone in much more of a direction of a DevSecOps, if the people listening to this and you will pardon the term. How did that happen? What was that product evolution like? Yeah, I think that's a fair assessment, actually. And again, no disrespect to D-Trace, of which I'm also a fan. So we certainly started out in the container observability space, essentially because this whole Docker Kubernetes thing was exploding in popularity.

I mean, even before it was exploding, it was just kind of like peaking out. And very quickly, our founder, Loris, who is the co-founder of Wireshark, was like, hey, there is a visibility issue here. We can't see inside these things with the tools that we have that are built for host instrumentation. So I'm going to make a thing. And he made a thing.

And it was an awesome thing that was open sourced. And then ultimately what happened is the ecosystem of containers and Kubernetes evolved. And more and more people started to adopt it. And so more and more people needed kind of a more, let's say, hefty, serious tool for observability. And then what followed was another tool for security, because what we actually discovered was the data that we're able to collect from the system with Sysdig is incredibly useful for noticing security problems. So that caused us to kind of expand into that space. And today we are very much a tool that still has an observability component that is quite popular, has a security component, which is itself fairly broad.

We cover CSPM use cases, we cover CIEM use cases, and we are very strong and very serious about our detection response and runtime security use cases, which come from that pedigree of the original Sysdig as well. You can get a fairly accurate picture of what the future of technology looks like by taking a look at what my opinion of something is and then doing the exact opposite of that. I was a big believer that virtualization, complete flash in the pan. Who's going to use that? Public cloud, are you out of your tree? No one's going to trust other companies with their holy of holies. And I also spent a lot of time crapping on containers and not actually getting into them. Instead, I leapfrogged over into the serverless land, which I was a big fan of, which you're running virtual machines that tend to be persistent, you really have to care about security because you are running full-on systems that are persistent, and they run all kinds of different services simultaneously. Looking at Lambda functions, for example, in the modern serverless world, I always find a lot of the tooling and services and offerings around security for that are a little overblown. They have a defined narrow input, they have a defined output, there usually aren't omnibus functions shoved in here where they have

all kinds of different code paths, and it just doesn't have the same attack surface, so it often feels like it's trying to sell me something I don't need. Security in the container world is one of those areas I never had to deal with in anger as a direct result. So I have to ask, how bad is it? We'll have some data to share with you, but I'll start by saying that I'm maybe was the opposite of you. So we'll see which one of us wins this one. I was an instant container fangirl from the minute I discovered them, but I crapped up. The industry shows you were right on that one. I think the jury is pretty much in on this one. Oh, I'll take it.

But I did crap on Lambda functions pretty hard. I was like, serverless? This is dumb. Like, how are we ever going to make that work? So it seems to be catching on a little bit, at least. It does seem like serverless is playing the function of like the glue between bits. So that does actually make a lot of sense in retrospect.

I don't know that we're going to have. But it feels like it started off with a whole bunch of constraints around it. And over time, they continued to relax those constraints. It used to be, how do I package this? It's, oh, simple. You just spend four days learning about all the ins and outs of this. And now it's, oh, yeah, you just give it a Docker file.

Oh, well, that seems easier. I could have just been stubborn and waited. Hindsight. Yeah, exactly. So containers, as they are today, I think are definitely much more usable than they were five plus years ago. Again, there's a lot of commercial support around these things. So if you're a big enterprise client and you don't really have time to fool around in open source, you can go and buy yourself a thing.

And they'll come with support, and somebody will hold your hand as you figure it out, and it's actually quite pleasant. wasn't. Whether or not that has really gone mainstream or whether or not we've built out the entire operational ecosystem around it in a, let's say, safe and functional way, there's ways to be seen. So I'll share some data from our report, which is actually kind of the key thing I want to talk about. Yeah, I wanted to get into that. You round up publishing this somewhat recently, and I regret that as of the time of this recording, I've not yet had time to go into it in depth and, of course, eviscerate it in my typical style on Twitter, although that may have been rectified by the time that this show airs, to be very clear.

But it's the Sysdig 2022 Cloud Native Security and Usage Report. Please at me when you Twitter, Fred it. Oh, when I read through and screenshot it and I make what observations that I imagine are witty. But I'm looking forward to it. I've done that periodically with the Flexera State of the Cloud Report for the last few years.

And every once in a while, whatever it is, we've done a piece of thought leadership and written a report. It's, oh, great, let's make fun of it. That's basically my default position on things. I am not a popular man, as you might imagine. But not having had the chance to go through it in depth, what did this attempt to figure out when the study was built, and what did you learn that you found surprising? Yeah, so the first thing I want to point out, because

it's actually quite important, is that this report is not a survey. This is actual data from our actual backend. So we're a SaaS provider. We collect data for our customers. We completely anonymize it. And then we show in aggregate what, in fact, we see them doing or not doing. Because we think this is a pretty good indicator of what's actually happening versus asking people for their opinion, which is, you know, their opinion. Oh, I love that. My favorite lies that people tell are the lies they don't realize that they're telling. It's, I'll do an AWS bill analysis, and great. So tell me about all these instances you have running over in Frankfurt. Oh, we don't have anything there. I believe you are being sincere when you say this. However, the data does show otherwise, and yay, now we're in a security incident. Exactly.

I'm a big believer of going to the actual source for things like this where it's possible. Exactly. So I'll say my biggest takeaway from the whole thing probably was that I was surprised by the lack of surprise. And I work in cloud native security, so I'm kind of hoping every single day that people will start adopting these modern patterns of like discarding images and deploying new ones when they've found a vulnerability and making ephemeral systems that don't run for a long time like a virtual machine in disguise and so on. And it appears that that's just not really happening. Yeah, it's always been fun, more than a little

entertaining when I wind up taking a look at the aspirational plans that companies have. Great. So what are you going to do? Oh, we're going to get to that after the next sprint. Cool. And then I just set a reminder and I go back a year later. How's that coming? Oh, yeah, we're going to get to that next sprint. It's the big lie that we always tell ourselves that right after we finish this current project, then we're going to suddenly start doing smart things, making the right decisions and the rest. And security, cost, and a few other things all tend to fall on the side of you can spend infinite money and infinite time on these things, but it doesn't advance what your business is doing. But if you do none of those things, you don't really have a business anymore. So it's always

a challenge to get it prioritized by the strategic folks. Exactly. You're exactly right. Because what people ultimately do is they prioritize business needs, right? They're prioritizing whatever makes them money or creates the trinkets they're selling faster or whatever it is, right? The interesting thing though, is if you think about who our customers would be, like who the people on this data set are, they are all companies who are probably more or less born in the cloud, or at least have some arm that is born in the cloud and they are all companies who are probably more or less born in the cloud, or at least have some arm that is born in the cloud,

and they are building software. So they're not really just your average enterprises you might see in a Gartner client base, which is more broad. They are software companies. And for software companies, delivering software faster is the most important thing, and then delivering secure software faster

should be the most important thing, but it's kind delivering secure software faster should be the most important thing, but it's kind of like the other thing that we talk about and don't do. And that's actually what we found. We found that people do deliver software faster because of containers and cloud, but they don't necessarily deliver secure software faster because as is one of our data points,

75% of containers that run in production have critical or high vulnerabilities that have a patch available. So they could have been fixed, but they weren't fixed. And people ask why, right? And why? Well, because it's hard. Because it takes time.

Because something else took priority. Because I've accepted the risk. You know, lots of reasons why. I can walk up and down the expo hall at the RSA conference, which until somewhat recently, you were not allowed to present at or exhibit at unless you had the word firewall in your talk title or wound up having certain amounts of fuds splattered across your banners at the show floor. It feels like there are 12 products, give or take, for sale there, but there are hundreds of booths because those products have different names, different messaging, and the rest, but it all feels like it distills down to basically the same general

categories. And I can buy all of those things. And it costs an enormous pile of money. And at the end of it, it doesn't actually move the needle on what my business is doing, at least not in a positive direction. You know, we just set a giant pile of money on fire to make sure that we're secure. Well, great. Security is never an absolute. And on top of that, there's always the question of what are we trying to achieve as a business? As a goal, from a strategic perspective, security often looks a lot like, please, let's not have a data breach that we have to report to people. And ideally, if we have a lapse, we find out about it through a vector that is other than the front page of the New York Times.

That feels like it's a challenging thing to get prioritized in a lot of these companies. And you have found in your report that there are significant challenges, of course, but also that some companies and some workloads are in fact getting it right. Right, exactly. So I'm very much in line with your thinking about this RSA shopping spree. And the reality of that situation is that even if we were to assume that all of the products you bought at the RSA shopping center were the best of breed, the most amazing, fantastic, perfect in every way, you would skilled enough to execute on that process, and who are more or less in agreement with the people next door to them who are stuck using one of the 12 trinkets you bought, but not the one that you're using. So I think that struggle persists into the cloud. It makes it be worse in the cloud because now not only are we having to create a process around all these tools so that we can actually do something useful with them, but the platform in which we're operating is fundamentally different

than what a lot of us learned on, right? So the priorities in cloud are different, the way that infrastructure is built is a little bit different, like you have to program a YAML file to make yourself an instance, and that's kind of not how we are used to doing it necessarily, right? So there are lots of challenges in terms of skills gap, and then

there's just this eternal challenge of like how do we put the right steps into place so that everybody who's involved doesn't have to suffer? And then the thing that comes out at the end is not garbage. So our approach to it is to try to give people all the pieces they need within a certain

scope. So again, we're talking about people developing software in a cloud-native world. We're focused on containers and cloud workloads, even if they're not necessarily containers. So that's our sandbox. But whoever you are, the idea is that you need to look to the left, because we say shift left, but then you have to follow that thread all the way to the right. And I actually think that the thing that people most often neglect is the thing on the right. They maybe check for compliance, they check configurations, they check vulnerabilities,

they check blah, blah, blah, all this checking and testing. They release their beautiful baby into the world and they're like, okay, I've washed my hands of it. It's fine, right? It has successfully been hurled over the fence. It is the best kind of problem now. Someone else's. Gone, yeah. But it's someone else's, the attacker community, right? Who are now like, oh, delicious, a new target. And like, that's the point at which the fun starts for a lot of those folks who are on the offensive side. So if you don't have any way to manage that thing's security as it's running, you're kind of like missing the most important piece, right? One of the challenges that I tend to see with a lot of programmatic analysis of this is that it doesn't necessarily take into

account any of the context because it can't. If I have, for example, a containerized workload, that entire job is to take an image from S3, run some analysis or transformation on it, and output the results of that to some data store. And that's all it's allowed to talk to. It can't ever talk to the internet. Having a system that starts shrieking about, ah, there's a vulnerability in one of the libraries that was used to build that container, fix it, fix it, fix it, doesn't feel like it's necessarily something that adds significant value to what I do. I mean, I see this all the time with very purpose-built Lambda functions that I have doing one thing and one thing only. Ah, but one of the dependencies in the JSON processing library could turn into something horrifying. Yeah, except the only JSON

it's dealing with is what DynamoDB returns. The only thing in there is what I've put in there, that that is not a realistic vector of things for me to defend against. The challenge then becomes when everything is screaming that it's an emergency when you know due to context that it's not, people just start ignoring everything, including the, oh, oh and by the way the building is on fire as one of the on page five that's just a small addendum there how do you view that the noise insecurity problem i think is ancient and forever so it was always bad right but in cloud at least in containers you would think it should be less bad, right? Because if we actually followed

these sort of cloud native philosophy of creating very, actually it's called the Unix philosophy from like, I don't know, before I was born, creating things that are fairly purposeful, like they do one thing, like you're saying, and then they disappear, then it's much easier to know

what they're able to do, right? Because they're only able to do what we've told them they're able to do. So if this thing is only able to make one kind of network connection, I'm not really concerned about all the other network connections it could be making, because it can't. So that should make it easier for us to understand what the attack surface actually is. Unfortunately, it's fairly difficult to codify and productize the discovery of that and the enrichment of the vulnerability information or the

configuration information with that that is something we are definitely focusing on as a vendor there are other folks in the industry that are also working on this kind of thing but you're exactly right the prioritization of not just a vulnerability but a vulnerability is a good example like it's a vulnerability right maybe it's a critical maybe it's not first of all is it exposed to the outside world somehow like can we actually talk to the system is it mitigated right maybe there's some other control in place that is mitigating that vulnerability so if you look at all this context at the end of the day the question isn't really like how many of these things can i ignore the question is at the very least which are the most

important things that i actually can't ignore so like you're saying like the building's on fire i need to know and if it's just like a smoldering situation, maybe that's not so bad, but I really need to know about the fire. This episode is sponsored in part by LaunchDarkly. Take a look at what it takes to get your code into production. I'm going to just guess that it's awful because it's always awful. No one loves their deployment process. What if launching new features didn't require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren't what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com and tell them Corey sent

you and watch for the wince. It always becomes a challenge of prioritization. And that has been one of those things that I think on some level might almost cut against a tool that works at the level that Sysdig does. I mean, something that you found in your report, but I feel like on some level is one of those broadly known or at least unconsciously understood things is you can look into a lot of these tools that give incredibly insightful depth and explore all kinds of neat, far future, bleeding edge, absolute front of the world, deep dive security posture defenses. But then you have a bunch of open S3 buckets that have all of your company's database backups living in them. It feels like there's a lot of walk before you can run. And then that on some level leads to the, wow, we can't even secure our S3 buckets.

What's the point of doing anything beyond that? It's easy to, on some level, almost despair or want to give up for some folks that I've spoken to. Do you find that that is a common thing, or am I just talking to people who are just sad all the time? is real, but I do think that we all end up in the same solution, right? The solution is defense and depth. The solution is layer control. So, the reality is, if you don't bother with the basic security hygiene of keeping your buckets closed and, like, not giving admin access to every random person and thing, right? If you don't bother with those things, then, like, you're right. You could have

all the tools in the world, and you could have the most advanced tools in the world, and you're just kind of wasting your time and money. But the flip side of that is people will always make mistakes, right? So even if you are doing, quote unquote, doing everything right, we're all human and things happen and somebody will leave a bucket open on accident or somebody will misconfigure some server somewhere, allowing it to make a connection it shouldn't, right? And so if you actually have built out a fault pipeline that covers you from end to end, both pre-deployment and at runtime

and for vulnerabilities and for misconfigurations and for all of these things, then you kind of have checks along the way so that this problem doesn't make it too far. And if it does make it too far and somebody actually does try to exploit you, you will at least see that attack before they ruin everything completely. One thing that I think Sista gets very right that I wish this was not worthy of commenting on,

but of course we live in the worst timeline, so of course it is, is that when I pull up the website, it does not market itself through the whole fear, uncertainty, and doubt nonsense. It doesn't have the scary pictures of, do you know what's happening in your environment right now? Or the terrifying statistics that showed that we're all about to die and whatnot. Instead, it talks about the value that it offers its customers. For example, I believe its opening story is run with confidence. Like, great, you actually have some reassurance that it is not as bad as it could be. That is, on the one hand, a very uplifting message, and two, super rare. Why is it that so much of the security industry resorts to just some of the absolute worst storytelling tactics in order to drive sales? That is a huge compliment, Corey, and thank you. We try very hard to be kind

of cool in our marketing. It shows. I'm tired of the 1990s era story of, do you know where the hackers are? And of course, someone's wearing a ski mask and typing with gloves on, which is always how I break into things. I don't know about you. But all right, we have the scary clip art of the hacker person, and it just doesn't go anywhere positive. Yeah.

I mean, I think there certainly was a trend for a while of this FUD approach. It's still prevalent in the industry in some circles more than others. But at the end of the day, cloud is hard and security is hard and we don't really want to add to the suffering. We would like to add to the solution, right?

So I don't think people don't know that security is hard and that hackers are out there and, you know, there's like ransomware on the news every single day. It's not exactly difficult to tell that there's a challenge there. So for us to have to go and like exacerbate this fear is almost condescending, I feel, which is kind of why we don't. Like we know people have problems and they know that they need to solve them. I think the challenge really is just making sure that, A, can folks know where to start and how to build a sane roadmap for themselves?

Because there are many, many, many things to work on, right? And we were talking about context before, right? So we actually try to gather this context and help people. You made a comment about how having a lot of telemetry might actually be a little bit counterproductive because there's too much data. What do I do? Here's the 8,000 findings we found that you failed. Great. Yeah. Congratulations.

You're effectively the Nessus report as a company. Great. Here you go. Everything is over. Yeah. Well, no shade of Nessus. Nessus did its thing. Oh, Nessus is fantastic. For those who are unaware, Nessus was an open-source scanner made by the folks at Tenable.

And what was great about it was that you could run it against an environment. It would spit out all the things that it found. Now, one of the challenges, of course, is that you could white label this and slap whatever logo you wanted on the top. And there were a lot of security consultancies, to use the term incredibly lightly, that would just run a Nessus report, drop off the thick printout, here's the 800 things you need to fix, pay me, and wander on off into the sunset. And when you have 800 things you need to fix, you fix none of them. And they would just sit there and atrophy on the shelf. Not to say that all those things weren't valid findings, but you know, the whole, you're using an esoteric, slightly deprecated TLS algorithm on one of your backend

services versus your Elasticsearch database does not have a password set. There are different levels of concern here. And that is the problem. Yeah, that is in fact one of the problems we're aggressively trying to solve, right? So we, because we see so much of the data, we're actually able to piece together a lot of context to give you a sense of risk, right? So we, because we see so much of the data, we're actually able to piece together a lot of context to give you a sense of risk, right? So instead of showing all the data to the customer, the customer can see it if they want, like it's all in there, you can look at it. One of the things we really try to do is collect enough information about the finding or the event or the vulnerability or whatever, so we can kind of tell you what to do. For example, one thing you

can do, this is super basic, but if you're looking at a specific vulnerability, like let's say it's Log4j or whatever, you type it in and you can see all your systems affected by this thing. Then you can, in the same tool, click to the other tab and you can see events associated with this vulnerability. So if you can see the systems that the vulnerability is on and you can see if there's weird activity on those systems. So if you're trying to triage some weird thing in your environment during the log4j disaster, it's very easy for you to be like, huh, okay, these are the relevant systems, this is a vulnerability, here's all that I

know about this stuff. So we kind of try to simplify as much as possible. My design team uses the word easeify, which I love. It's a great word. To easeify the experience of the end user so that they can get to whatever it is they're trying to do today. Like, what can I do today to make my company more secure as quickly

as possible? So that is sort of our goal. And all this huge wealth of information we gather, we try to package for the users in a way that is in fact digestible and not just like, here's a deluge of suffering. Like, look, you know. This is definitely complicated in the environment I tend to operate in, which is almost purely AWS. How much more complex does this get when people start looking into the multi-cloud story or hybrid environments where they have data centers talking to things within AWS? Because then it's not just the expanded footprint, but the entire security model works slightly

differently in all of those different environments as well. And it feels like that is not a terrific strategy. Yeah, this is tough. My feelings on multi-cloud are mostly negative, actually. Well, thank goodness it's not just me. I was going to say that like, like multi-cloud is not a strategy. It's just something that happens to you.

Same with hybrid. No one plans to do hybrid. They start doing a cloud migration, realize halfway through some things are really hard to move, give up, plant the flag, declare victory, and now it's called hybrid. No one plans to do hybrid. They start doing a cloud migration, realize halfway through some things are really hard to move, give up, plant the flag, declare victory, and now it's called hybrid.

Basically, my position, and again, as an analyst, you kind of, I think, end up in this position of you just have a lot of sympathy for the poor people who are just trying to get these stupid systems to run.

And so I kind of understand that, look, nothing's ideal and we're just going to have to work with it. So multi-cloud, I think, is one of those things where it's not really ideal. We have to work with it. So multi-cloud, I think, is one of those things where it's not really ideal. We have to work with it. There's certainly advantages to it. There's presumably some level of mythical redundancy or whatever, I don't know. But the reality is that if you're trying to secure a pile of junk in Azure and a pile of junk in AWS, it'd be nice if you had one tool that told you what to do with both piles of

junk. In some sense, we do do that. And in fact, it's very difficult to do that if you're not a third-party tool, because if you're AWS, you don't have much incentive to, like, tell people how to secure Azure, right? So any tool in the category of, like, a third-party CSPM, Gartner calls them CWPP, kind of cloud security,

is attempting to span those clouds because they almost have to to be relevant. Otherwise, like, what's the point, right? Well, I would argue cynically there's also the VC model, where, oh, great, if we cover multiple cloud providers, that doubles or triples our potential addressable market. And okay, great. I don't have those constraints, which is why I tend to focus on one cloud provider where I tend to see the problems I know how to solve as opposed to trying to conquer the world. I guess I have my bias on

that one. Fair, but I think the barrier to entry is lower as a security vendor, right? Especially if you're doing things like CSPMs, to take an example. So if you're looking at compliance requirements, right? If your team understands what it means to be compliant with PCI, like line three or whatever, you can apply that to Azure and Amazon fairly trivially. And be like, okay, well, here's how I check in Azure, and here's how I check in Amazon, right?

So it's not very difficult to, I think, engineer that once you understand the basic premise of what you're trying to accomplish. It does become complicated as you're trying to deal with more and more different cloud services. Again, if you're kind of trying to be a cloud security company, you almost have no choice. Like, you have to either say, I'm only doing this for AWS, which is kind of a weird thing to do, because they're kind of doing their own half-baked thing already, or I have to do this for everybody. And so most defaults are doing it for everybody. Whether they do it equally well for everybody,

I don't know. From our perspective, like there's clearly a roadmap. So we have done one of them first and then one of them second and one of them third. And so I guarantee you that we're better in some than others. So I think you're going to have pluses and minuses no matter what you do. But ultimately, what you're looking for

is coverage of the tool's capabilities and whether or not you have a program that is going to leverage that tool, right? And then you can check the boxes of like, okay, does it do the AWS thing? Does it do this other AWS thing? Does it do this Azure thing? I really appreciate you taking the time

out of your day to speak with me. We're going to throw a link to the report itself in the show notes. But other than that, if people want to learn more about how you view these things, where's the best place to find you? I am rarely, but on Twitter at A-A-B-E-L-A-K. I am also on LinkedIn like everybody else. And in the worst case, you can find me by email at Annana.bellic.systig.com. And we will, of course, put links to that in the show notes. Thank you so much for taking the time to speak with me today. I appreciate it. Thanks for having me, Corey. It's been fun. Anna Bellic, Director of Thought Leadership at Sysdig. 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 comment telling me not only why this entire approach to security is awful and doomed to fail, but also what booth number I can find you at at this year's RSA conference. 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