Announcer: 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.

Corey: 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 100 megabyte binary that doesn’t eat all the data you’ve gotten on the system, it’s exactly what you’ve been looking for. Check it out today at min.io/download, and see for yourself. That’s min.io/download, and be sure to tell them that I sent you.

Corey: This episode is sponsored by our friends at Oracle HeatWave is a new high-performance query accelerator for the Oracle MySQL Database Service, although I insist on calling it “my squirrel.” While MySQL has long been the worlds most popular open source database, shifting from transacting to analytics required way too much overhead and, ya know, work. With HeatWave you can run your OLAP and OLTP—don’t ask me to pronounce those acronyms again—workloads directly from your MySQL database and eliminate the time-consuming data movement and integration work, while also performing 1100X faster than Amazon Aurora and 2.5X faster than Amazon Redshift, at a third of the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense.

Corey: 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 Belak. Anna, thank you for joining me.

Anna: Hi, Corey. I’m very happy to be here. I’m a big fan.

Corey: 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?

Anna: I command the Council of the Lords of thought, actually. [laugh].

Corey: Supply chain issues mean the robe wasn’t available. I get it, I get it.

Anna: 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 it 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.”

Corey: You know, it’s one of those titles that people generally don’t see a whole lot of, so 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 because, in lieu 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.

Anna: 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-native workloads, which is kind of how I ended up here.

Corey: 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 [laugh] 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, strace, and the rest. Honestly—and I mean no slight to the folks who built out this particular tool—it felt like DTrace, only it understood the value of being accessible to its users without basically getting a doctorate in something.

I like 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 DevSecOps, if the people listening to this, and you, will pardon the term. How did that happen? What was that product evolution like?

Anna: Yeah, I think that’s a fair assessment, actually. And again, no disrespect to DTrace 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, 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’s 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 communities evolved, and more and more people started to adopt it. And so 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 it’s fairly broad: We cover CSPM use cases, we cover [CIEM 00:05:04] use cases, and we are very, kind of let’s say, 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.

Corey: 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 of course means that it’s going to be doomed sooner or later. My security position has also somewhat followed similar tracks where, back when 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?

Anna: Well, I have some data to share with you, but I’ll start by saying that I 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 out—

Corey: The industry shows you were right on that one. I think the jury [laugh] is pretty much in on this one.

Anna: Oh, I will 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. 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—

Corey: Well, it feels like it started off with a whole bunch of constraints around it, and over time, they’ve continued to relax those constraints. It used to be, “How do I package this?” It’s, “Oh, simple. You just spent 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.

Anna: Yeah, exactly. So, containers as they are today, I think are definitely much more usable than they were five-plus years ago. There are—again there’s a lot of commercial support around these things, right? So, if you’re, you know, like, a big enterprise client, then you don’t really have time to fool around in open-source, you can go in, 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, quite pleasant. 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 remains 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.

Corey: Yeah, I wanted to get into that. You wound up publishing this somewhat recently, and I regret that as of the time of this recording, I have 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”.

Anna: Please at me when you Twitter-shred it. [laugh].

Corey: Oh, when I read through and screenshot it, and I’d 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 last few years, and every once in a while, whatever there’s a, “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?

Anna: 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 back end. 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.

Corey: 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’re being sincere when you say this, however, the data does show otherwise, and yay, now we’re in a security incident.

Anna: Exactly.

Corey: I’m a big believer of going to the actual source for things like this where it’s possible.

Anna: Exactly. So, I’ll tell you 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 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.

Corey: 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 when 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, and, “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 finished this current project, then we’re going to suddenly start doing smart things, making the right decisions, and the rest. 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.

Anna: Exactly. You’re exactly right because what people ultimately do is they prioritize business needs, right? They are prioritizing whatever makes them money or creates the trinkets their 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 in this dataset 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 building software, right? 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, right, and then 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.

Corey: One of the big challenges, I think, is that I can walk up and down the expo hall at the RSA Conference, which until somewhat recently, you were not allowed to present that or exhibit at unless you had the word ‘firewall’ in your talk title, or wound up having certain amounts of FUD 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 in some workloads are in fact getting it right.

Anna: 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 still have to somehow build a program on top of them. You have to have a process, you have to have people who are bought into that process, who are 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 and may actually be worse in the cloud because now, not only are we having to create a processor on 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 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, right, and that 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 kind of on containers and cloud workloads even though it’s not necessarily containers. So that’s, like, our sandbox, right? But whoever you are, right, the idea is that you need to look to the left—because we say ‘shift left’—but then you kind of 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, right? They maybe check for compliance, you know, they check configurations, they check for 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 wash my hands of it. It’s fine. [laugh]. Right but—

Corey: It has successfully been hurled over the fence. It is the best kind of problem, now: Someone else’s.

Anna: It’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? [laugh].

Corey: 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’s entire job is to take an image from S3, run some analysis or transformation on it then output the results of that to some data store, and that’s all it’s allowed to talk to you, 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 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, and by the way, the building is on fire,” as one of—like, on page five, that’s just a small addendum there. How do you view that?

Anna: The noise insecurity problem, I think, is ancient and forever. So, it was always bad, right, but in cloud—at least some containers—you would think it should be less bad, right, because if we actually followed these sort of cloud-native philosophy, of creating very purp—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 enabled to make one kind of network connection, like, I’m not really concerned about all the other network connections it could be making because it can’t, right? 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 or maybe it’s not.

First of all, is it exposed to the outside world somehow? Like, can we actually talk to this system? Is it mitigated, right? Maybe there’s some other controls 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 buildings 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.

Corey: 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.

Corey: 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, want to give up, for some folks that I’ve spoken to. Do you find that is a common thing or am I just talking to people who are just sad all the time?

Anna: I think a lot of security people are sad all the time. So, the despair is real, but I do think that we all end up in the same solution, right? The solution is defense in 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 flipside of that is, people will always make mistakes, right? So, even if you are, 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 full pipeline that covers you from end-to-end, both pre-deployment, and at runtime, and for vulnerabilities, and 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’ve ruined everything completely.

Corey: One thing I think Sysdig 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 show 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?

Anna: That is a huge compliment, Corey, and thank you. We try very hard to be kind of cool in our marketing.

Corey: It shows. I’m tired of the 1990s era story of, “Do you know where the hackers are?” And of course, someone’s wearing, like, 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.

Anna: Yeah. I mean, I think there certainly was a trend for a while have this FUD approach. And 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?

We were talking about context before, right? Like, 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, like, there’s too much data, what do I do well—

Corey: Here’s the 8000 findings we found that you fail—great. Yeah. Congratulations, you’re effectively the Nessus report as a company. Great. Here you go.

Anna: Everything is over.

Corey: Yeah.

Anna: Well, no shit, Nessus, you know. Nessus did its thing. All right. [laugh].

Corey: Oh, Nessus was fantastic. Nessus was—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’ that use the term incredibly… lightly, that would just run a Nessus report, drop off the thick print out. “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 back-end services, versus your Elasticsearch database does not have a password set. Like, there are different levels of concern here. And that is the problem.

Anna: Yeah. That is in fact one of the problems we’re aggressively trying to solve, right? So, because we see so much of the data, we’re actually able to piece together a lot of context to gives 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’re really trying 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 you can do this is super basic, but if you’re looking at a specific vulnerability, like, let’s say it’s like Log4j or whatever, you type it in, and you can see all your systems affected by this thing, right? Then you can, in the same tool, like, 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 there’s weird activity on those systems, right? 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 the vulnerability. Like, 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 ‘easify,’ which I love; it’s a great word—to easify, 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.” [laugh]. You know?

Corey: This is definitely complicated in the environment I tend to operate in which is almost purely AWS. How much more complex is get when people start looking into the multi-cloud story, or hybrid environments where they have data center is 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.

Anna: Yeah, this is tough. My feelings on multi-cloud are mostly negative, actually.

Corey: Oh, thank goodness. It’s not just me.

Anna: I was going to say that, like, multi-cloud is not a strategy; it’s just something that happens to you.

Corey: 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.

Anna: Basically. But my position—and again, as an analyst, you kind of, I think, end up in this position, 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, like, 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 just have to work with it. There’s certainly advantages to it, like, 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, like, it’d be nice if you had, like, one tool that told you what to do with both piles of junk, and sometimes 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, third-party CSPM—Gartner calls them CWPP—kind of, cloud security is attempting to span those clouds because they always have to be relevant, otherwise, like, what’s the point, right?

Corey: 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.

Anna: Fair. But there’s—I think the barrier to entry is lower as a security vendor, right? Especially if you’re doing things like CSPMs. Take an example. So, if you’re looking at compliance requirements, right, if your team understands, like, what it means to be compliant with PCI, you know, like, [line three 00:28:14] 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 default to 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 the 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?”

Corey: I really appreciate your 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 00:29:23], but other than that, if people want to learn more about how you view these things, where’s the best place to find you?

Anna: I am—rarely—but on Twitter at @aabelak. I am also on LinkedIn like everybody else, and in the worst case, you could find me by email, at anna.belak@sysdig.com.

Corey: And we will of course put links to that in the [show notes 00:29:44]. Thank you so much for taking the time to speak with me today. I appreciate it.

Anna: Thanks for having me, Corey. It’s been fun.

Corey: Anna Belak, Director of Thought Leadership at Sysdig. I’m Cloud Economist Corey Quinn and this is streaming on 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 this year’s RSA Conference.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Announcer: This has been a HumblePod production. Stay humble.