Screaming in the Cloud - Exploring Advanced Cybersecurity with Michael Isbitski

Episode Date: February 6, 2024

Cybersecurity leader Mike Isbitski explores the intricacies of cloud-native security and vulnerability management in today's technological landscape. With over 25 years of experience, he provides valuable insights into the challenges and complexities organizations face in securing ephemeral infrastructure and machine identities in the cloud. This episode also explores the cautious adoption of AI in cybersecurity, emphasizing the need for a balanced approach that maintains operational functionality while addressing evolving security concerns.Key Points with TimestampSecurity through Obscurity (00:00:00) - Mike discusses common security practices.Cloud-Native Technology Explained (00:01:30) - Unpacking the meaning of cloud-native tech.Evolving Vulnerability Management (00:03:38) - Insights on how vulnerability management has improved.AI in Cybersecurity (00:21:20) - Discussion on the slow but growing adoption of AI in cybersecurity.Challenges of Permissions and Identity (00:29:29) - The complexities of permissions in the cloud environment.Future Trends in Cybersecurity (00:34:11) - Predictions for changes and advancements in the cybersecurity landscape.About MichaelMichael Isbitski is a former Gartner analyst, cybersecurity leader, and practitioner with more than 25 years of experience, specializing in application, cloud, and container security. Michael learned many hard lessons on the front lines of IT working on application security, vulnerability management, enterprise architecture, and systems engineering. He's guided countless organizations globally in their security initiatives as they support their businesses.Links Referenced:Sysdig: https://sysdig.com/Sysdig 2024 Cloud-Native Security and Usage Report: www.sysdig.com/SITC

Sometimes the language I'll use that's kind of become common language, certainly with security practitioners, is it's kind of like security through obscurity. Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted guest episode is brought to us by our friends at Sysdig. And Mike Izbitski is our guest today. He's the director of cybersecurity strategy. Welcome back, Mike. How have you been? I've been great, Corey. He's the director of Cybersecurity Strategy. Welcome back, Mike. How have you been?

I've been great, Corey. It's been a year. A lot of things have happened, but yeah, it's really great to be here and talk with you again. What was the one, the days are short, but the years are long?

It's always this really weird approach to just passing of time. It's 2024 now, and I'm talking about things like, oh yeah, five years ago. Like, oh, that wasn't five years. That was 2019. Oh no. Time moves fast, especially with little ones. Dear Lord. Teaching the talk was the greatest mistake. So it is 2024. And that can mean only one thing. The Sysdig 2024 Cloud Native Security and Usage Report. So much to tear into.

Let's start at the beginning with titles. Cloud native. What does it mean? It's like the proverbial question, right? And without getting too philosophical, I mean, where I usually start with this and, you know, even for my analyst days, it was container focused, right? Or container. Containers are kind of at the heart of the thing. The name's almost misleading, right? It doesn't necessarily need to be cloud hosted, but the technologies that power cloud are part of the equation. So typically that's containerized services.

But then you get into whole serverless approaches, event-driven architectures, that counts it as well. Increasingly, and I'm cynical here, I'm not targeting you folks directly. I'm not exempting you either because I think everyone does it now. Increasingly, cloud native is used to mean things I can sell you.

It's more of a branding and positioning thing. Whereas, like, oh, we have an appliance that we've turned to an AMI. It's cloud native. It's a, is it though? Yeah. It's a bone that I'm picking, but it's also a war that I've lost,

similar to the term thin ops. I think that's a bad term, but everyone's using it at this point and I'm not going to be like the last person raging against the tide trying to defend my sandcastle. Yeah, I mean, I was seeing some of that certainly from vendors, like they would sell a cloud service.

It wasn't actually fully cloud enabled. Yeah, they'd kind of give you a virtual machine that could operate in the cloud. So is it taking full advantage of those, you know, native, to use the term, right, that we're trying to define? But those things that power the clouds that Amazon and Microsoft and Google are using, that is essentially it, right? So when you dig in a few layers, it's absolutely containers, Kubernetes, serverless, venture-driven architecture. Turtles, all of it the way down. Oh, yeah. And lots of the complexity, right?

Lots of things to break. So on some level, this is the 2024 report, and you can compare that to the 2023 report. And, you know, on some level, it's okay. I think that the sequel might not have done as much service as I was hoping. There's not a whole lot of new plot development. I find the protagonist still relatively unrelatable. But what have you noticed that are big shifts that have happened in a year? We talk about days short, years being long. What's changed in 12 months?

I'd say some of our customers, actually a good percentage of them got better at vulnerability management. Last year, we talked a lot about the concept of runtime insight and providing runtime context to make better risk-informed decisions, right? Ideally, you're doing all kinds of testing early and often in the lifecycle of an application or the workloads that support it. You might be finding instances of vulnerabilities that should be fixed prior to deploying that production, and then you fix that thing. But typically, what organizations run into is as they start scanning, they find more and more issues, right? Commonly that's CVE ID, right?

Then they start looking at CVSS scoring. What's the criticality of that particular vulnerability? But you still have a mountain of things that you just don't know what to fix, right? So it's the Dependabot problem. I've been ranting about this for a while now, where I wind up, it feels like it's the human Nessus scan at this point, only not human in that particular case, because, oh, here's a whole bunch of critical problems

you need to fix, and is it though? It's in a library that my application depends upon. That application is purely internal, will only ever see sanitized inputs, and has a defined output. I don't actually care about this. But that that noise obscures things that actually do pose some risk theoretically to a bunch of things. I am, to be direct, a little less security concerned with the stuff that I'm talking about, because it tends to be stuff that works on the back end to help my

newsletter get written. The worst case compromise story here, it's a completely distinct system from anything that has recipient email addresses. So all someone's going to be able to do is breach the things I'm going to be writing about in four more days, or worst case, insert garbage into my queue, which would be annoying for me, but has no real impact. It's juxtaposing risk versus consequences on it. I could spend weeks of my time and significantly complicate my entire flow and structure to lock a lot of those things down more than they are, but there's no real reason to. It winds up impeding usability and there's no business value to me in doing that. Whereas when I say, I said this about things like the customer data that I'm entrusted with for my consulting projects.

If I were to say that, I would very quickly not have customers anymore. We have built that in some of the best ways that we know how. And then, and I think people miss this step, we brought in security experts to look at it and so we're not in a situation of violating Schneer's law who says that,

Bruce Schneer's a big fan of saying that anyone can devise a cryptographic algorithm that they themselves cannot break. Security is kind of the same way. So bring in people who are sneakier than I am and do this stuff a lot. And I think I'm checking the boxes and doing what I should be doing, but you're the expert. Tell me if I'm wrong. There's value in that. Yeah. And I'm glad you brought up the point, Corey. So it's absolutely true, right? It's like you have to start thinking about the business context. Sure, that vulnerability might be critical as rated by MITRE, but is that mitigated with some other control in my enterprise, right? So businesses really are looking at the complete picture. They can't fix everything. And you kind of hit the nail on the head.

Not everything's in use, right? So why even chase those vulnerabilities? So that's the reality of modern vulnerability management. You're not going to address everything. But a lot of what's also changed, kind of stepping outside of just the system report, is kind of the regulatory landscape. So we saw the finalization of the SEC cybersecurity disclosure requirements, and it very much talks about some of the things you were alluding to. It's, you know, well, what's the, to use their language, material impact, right? Which is going to be your business

impact. So if you were publicly traded or doing business with publicly traded entities, well, you might have an incident that results from that. And it's not kind of in the terms that a practitioner, a security practitioner might think of, right? Like they often just kind of jump right to data breach. It's, is there some kind of business impact to you, right? So you talked about customer names, like loss of that kind of intellectual property, right? But it's probably also governed data type. And even now, let's be serious for a second here, right? My business fixes large AWS bills

for companies. The data that I have involves how much money big companies pay a giant company. And if that gets leaked, I'll get sued into oblivion. I will have lost the trust of my customers. And that's important. But nobody dies. There is no, people view these things as confidential information, sure. But it's not, in almost any case, trade secret level of information that's going to materially impact their ability to do business. It might cause a scandalous news cycle, and there's not going to be a whole lot of real downstream impact from that. Contrast that to the scariest job I ever had doing operations stuff briefly at Grindr,

where if we got breached, people could die. Everything compared to that, this is just money and corporate money at that. I sleep very well at night as a result. I intentionally don't want corporate secrets of massive import. I'm not running a password manager here. I'm fixing large company cloud bills. One of those is a very different risk profile from the other. Yeah, it hits on a very good point, right? You kind of talked about safety, you know, and within the umbrella of cybersecurity regulation, there's the concept of resiliency.

But that information would be materially impacting, right? If you have financial numbers about whatever publicly traded entity, it could impact the decisions of a reasonably informed investor, right? And that's kind of the SEC's charter. They need to protect them. Yes and no. It's a fair point. The counter argument is, is if you take some random publicly traded company that's worth, I don't know, market cap of 20 billion, let's say for the sake of argument, and you find that they're at a year, they're spending $20 million on AWS versus $120 million on AWS. That is a sixfold difference. In either scenario, though, it's just a data point in isolation.

Is that, does that tell you anything about their business? But given that I made them up, it's, well, that could be either one could be a problem depending, or it could be great. But it just with that data point, there's nowhere near enough information to figure that out. It would be a piece of a puzzle. It's not the answer to anything. Yeah. And that's kind of a, where, where, how do you gauge materiality, which is probably a conversation for several podcasts, but it's absolutely true. Right. And things, and it shifts, right. It becomes a dynamic thing in context of other events. Right. So like those numbers in isolation, that's fine. You might not be able to correlate that to some other activity.

But then if you now map that to these companies cybersecurity expenditure and making kind of assessments about their security posture. Well, that could kind of lead into that material impact that would need to be disclosed. So, yeah, it gets kind of becomes quite a bit of a quagmire. But going back to kind of vulnerabilities that would lead to that, it's kind of that sequence of things that could lead up, right? If you know you have known vulnerabilities, you should be addressing them, certainly if it's in use in runtime.

Yeah. One thing that your report does not touch on, at least that it did, I did not see it when I went through it. And this has been the case forever. But a long time ago, the internet collectively decided for a variety of reasons and pressures and constraints that the cornerstone of your entire online identity is your email inbox. So it's people talk about compromising credentials out of environments and the rest and, and exploiting software vulnerabilities.

There's a story of if I can get access to your email, I can become you. And that is a, that is something that most people like to hand wave away. So when I talk to companies that are adamant about enabling multi-factor auth, whenever they're getting into their cloud account. That's great. And then you dig and turn out they don't do that for their email. It's, what are you doing there? It's like everyone trying to massively remove single points of failure from their environment in the cloud, but not the credit card that's the payment instrument and going to an email address that the founder never checks anymore. So there's always a question of, have you thought through these things to their logical conclusions?

And that's that is something that I don't necessarily fix. It's certainly out of scope for what Sysdig does. But the stuff that's in scope, the things that you turned up in this report, a couple of things I found surprising. I was just going to kind of validate, right, the landscape of all your identities and where you assign access controls. But we get into consumption patterns and the things that SysTick might see. But yeah, go ahead. There was a

second part to your question. The way that I think about these things comes from my background when I was tinkering around with these things many moons ago where when we talked about servers having distinct identities, virtualization was treated with suspicion. Containers, I would say they don't exist, but containers are from the 70s. LPAR is on mainframes, and they've been iterating steadily

ever since. But containers are not a thing in the same way. Even when I talk about email, for example, I talk about long-term, sustained, persistent attacks. The world doesn't always work that way. A lot of jobs are very short-lived, ephemeral containers. One of the key findings that you have in your report is that ephemeral, short-lived containers do not help from a security perspective, or if they do, not nearly as much as people believe that they do. Yeah, it's an interesting one. I sometimes gloss over this probably because I've just been looking at the technology too long. It's kind of like you accept that's not necessarily like a security boundary. Sometimes the language I'll use that's kind of become common language, certainly with security practitioners, is it's kind of like security through obscurity, right?

So you're abstracting the operating system from the workload, much like you're abstracting the hardware from the operating system when you talk about virtualization. So you're kind of adding complexity, really, but you're kind of inhibiting visibility. But it's another layer of abstraction when you start talking about containers. So this is actually a big one with visibility, right? Which becomes part of, well, how do I actually determine if an incident is relevant, right? Did it create security risk for my organization? And then it doesn't have material impact, but it's often where organizations aren't prepared, right? Even if they have the engineering staff

that they're looking at containers, they're not thinking about, you know, that full sequence of events. Like if somebody does attack a containerized service, am I getting all the right telemetry? And you raised the point about lifetime of the container, the ephemerality, it's only alive for five minutes. Did I actually retain all those signals

that now I can kind of stitch together the events and quickly enough, right? Because there's also the whole concept of real-time, right? Or as close to that as you can get in cloud. And we can certainly go down that path. But the regulations are very clear on this. You need to kind of be in that spot that you can detect incidents in real-time so you can very quickly make that determination around materiality. And then do I have to disclose this to whatever governing body, right? We talked about the SEC, but, you know, it might be in the EU, and you're bound by the

NIS 2 directive, so that needs to be disclosed to those appropriate entities. So, gathering the right telemetry throughout the tech stack becomes incredibly important. Certainly, assisted customers are prepared for that, because, like, that's kind of what we call out, right? They're very mature in their threat detection and response. They often seek out Sysdig for that reason, right? I need to have that visibility within the containerized architecture so I can do all these things that inform my risk management and vulnerability management. Well, hang on a sec. I'm going to challenge you on that because historically the problem you have with a lot of those telemetry solutions, and again, I've not gone deep into the weeds at a scaled out system with SysTank. I don't run scaled out systems anymore. Everything I do tends to be very small. It's like, is it really a big

data problem if it fits in RAM on a single machine? It's that type of problems here. But there's always been a challenge where even with some of the small stale experiments I'm doing, it's, wow, those logs never shut up for a second, kind of like me on Twitter. So you wind up with a needle in a haystack problem. And in some cases, I've talked to people who, of course, I will not name, who have taken a position privately that, frankly, if you record a lot of this data,

you're never going to be able to go through it. So all you're really doing is providing the smoking gun evidence later so you can get yelled at for, see, if you'd been looking through this, you would have seen the signs of the breach. So I don't keep it. So I don't get fired. I don't think that that's a terrific approach to take, but it is something that I see people talking about over drinks. Yeah, it's absolutely true. Right. And I'd say every cloud provider will say publicly that they give you the telemetry, although we've seen very specific kind of language from governing bodies in nation states that cloud providers might need to do more and offer more, right? You shouldn't have to pay more for detailed logs, but you absolutely hit the nail on the head, right?

Just the presence of that log data isn't enough. You also need to be doing things with it. I think you spoke with my colleague, Annabelle, a few weeks ago on the 555 benchmark. And there's a very specific component of that, which is about correlating these signals, right? So you have to pick up that needle in the haystack or the sets of the needles, right? Correlate them very quickly. So now you can actually determine what the appropriate response is for that incident. Yeah, there are a whole bunch of mess stories on these things.

How do you handle the analysis of it? How do you find the signal from noise? It's a great, congratulations. Your job as an intern now is to read all the logs as they come in with a tail dash F. It's like your best friend is grep to start, but where do you go beyond that? And then you find out somebody didn't actually turn up the log for that given service. Yeah. And I talk about old school systems that are around for calendar time. One of the big

changes we found with ephemeral infrastructure is even ignoring the security piece for a second, as so many people do for way more than a second, is if you have a problem in an environment that's an ephemeral container and you got alerted about it, but that container stopped existing 20 minutes ago, how do you reconstruct what happened? How do you diagnose it? And that required, that is where observability fundamentally came from, is you need to make sure that you have telemetry and an understanding of these distributed systems in order to track this. Yeah, it's kind of a very different way of looking at it. And it's kind of hard to wrap your brain around it until you actually start tinkering with containerized services. So by all means, set it up on your own Raspberry Pi or spin it up in the cloud provider of choice. But

expect the trial credits to exhaust very quickly, right? Because if you're going to spin up a Kubernetes cluster... Funny you say that. Last week, I built myself a Kubernetes. Not multiple, just the one. It's a single controller cluster that I have running in the spare room and a bunch of raspberries pie. And someone asked,

well, why didn't you just run this on EKS? It's because I do this for a living and I'm still worried about the surprise billing aspect potential if something goes into a crash loop or I wind up not paying close enough attention. Like, well, don't you understand how the bills work better than most?

Like, I'd say better than nearly everyone. And that's why I'm scared of it for my own personal side projects. It's kind of surprising. Like even, I mean, you said it, right? You could spin up a very bare bones cluster and it's been a bit since I've done it, but I would say at that time logging was disabled, right?

Because as soon as you turn up logging, you're going to be generating that much more service traffic within the cluster, but then you have data storage needs that might not be allocated to that trial account. So maybe two or three days and then you're going to hit the wall on your trial. But yeah, they're very chatty, right, to borrow that network engineering terminology, right? Logs fill up very fast. And when you're talking about abstracted services, containers running in virtualized machines, running on hardware, which you're not going to see, right? AWS or Azure would kind of see that end of the equation,

but you're seeing the other pieces of the infrastructure and it's very challenging to know what specifically is going on, right? And then you don't want to use the blunt hammer approach and just shut down an entire VM that might be running a thousand containers, right? And then what's the production impact? Who knows? So yeah, that visibility or having the appropriate signals to know what the heck's going on. I guess there's a little bit of overconfidence, right? Well, we have our trails turned up. We're gathering everything. We got audited sufficiently or we satisfied the audits for that. But is it providing the right container context?

If you are doing kind of a cloud native development to circle back on where we started the conversation, which many organizations are, right? Maybe not for the entire app portfolio, but certainly some things that they need to iterate quickly on. There's other stuff that was in the report that I found interesting as well. You talk about AI adoption growing slowly. And that's in isolation. That's a fascinating statement because everyone's talking about it. It's massively hyped. I've been doing a bunch of work with it myself. And my bill for all of that comes into less than $30 a month because these are all onesie twosie experiments, a lot of interactive exploration. And I talk to my

clients and I see that across the board as well. Everyone's doing something with it, but I have not talked to anyone yet who said, well, it's time for contract renewal and we're forecasting $100 million over the contract period, but we're doing some stuff with generative AI. So let's make it 150. No one is saying that.

It is not a driver of spend in any meaningful way yet. It's a driver of intense interest, but that is not the same thing. Yep, and there's different consumption patterns, right? I started to get at this, like a lot of buzz was caused by open AI with the launch of chat GPT. Oh, it's a magic box from the future.

And absolutely, there is value there. I don't want people to think this is another blockchain where people have been hyping it up for 10 years, but there's nothing, there's no there, there. Although there's AI blockchains. Of course, there are AI blockchains. I prefer the original blockchain. I call it Git. And someone's going tochains. Of course there are AI blockchains. I prefer the original blockchain. I call it Git.

And someone's going to say, well, what about B-trees? And I'm going to tell them to go back to computer science class. But that's a separate problem. Yeah, I'm kind of in the same boat, right? I've run a lot of kind of tinkering on the side, you know, instead of just the generic Google search. It's, you know, you can enroll in the Google Labs and then you get kind of analyzed search results, which is fun, right? It kind of saves you. It's fun, but it's also kind of productive.

It saves you from running sequences of searches, right? It's going to stitch together the information for you. So it's doing things that I'd say, as humans, we're just not used to having machines that can do that work for us. Like it was, it tend to be, give the computer a very simple problem, gives an answer. Now I got to piece together everything because the machine's dumb. So generative AI is kind of pulling those things together. I mean, this is a very simplified explanation,

but it's the way, kind of the general use case. It can, and it can be used in a lot of different ways. Like in healthcare, maybe it's going to give you very specific or close to specific guidance for your specific situation.

Well, like a counter argument to this is that they all struggle with this is honestly, they have the same flaw as a lot of people that I've known in the course of my life, which is if they don't know the answer, they're loathe to admit it. Yeah. And I'd say maybe a little bit of recency bias too, right? Because you're like, well, what's the currency of the data? How current is that data? What has it like, well, what's the currency of the data? How current is that data? What has it been trained on? There's that. There's in many cases,

it will extrapolate and go from there. One of the big consultancies recently said they're using generative AI to set their corporate strategy, which is not a statement I would ever have made because it's what you're saying is basically this magic parrot that is a spectacularly good bullshit generator in many respects. And the world runs on bullshit and a bunch of approaches, but is that something you really want to use? I mean, I use it myself for a variety of creative endeavors. For example, if I've written a blog post, I will sometimes slap that whole blog post into generative AI and say, give me 10 title options for this. And usually it's like, okay, number four is pretty good. Let me see if I

can punch that up myself. It's a yes and improv writer's room style approach. And using it in that respect, yeah, it's someone to talk to, provided you can trust the sanctity of the data, but it can't make decisions inherently. And if you start trusting it to do that, that becomes dangerous. I'm sure you've seen, the Cambrian explosion of inbound cold emails that are clearly written via AI. And it's because as soon as you give it more than a glance, like this makes absolutely zero sense whatsoever, but it is written in a somewhat compelling way. Like I would never in a million years send out something at this stage of the game that generative AI had written to outside people without humans reviewing it first. So all these chatbots on websites, no thank you. But that's not the space that you play in.

What are you seeing with AI adoption? Yeah, so we broke out the statistics, right? And it's, you have to remember, we're kind of seeing how people are engineering their applications and the infrastructure. So what are the specific workloads in their cloud instances or on-prem, right? And maybe their hybrid deployment, which are many customers, but what are the specific packages used to power AI, right? So not saying OpenAI as a customer, I'm actually not even sure if they are, But what are they using to power their infrastructure? What are the specific packages they use to power the large language model that powers the Gen AI? Right. And then there's kind of image recognition libraries as well.

Right. When you start talking about the visual side of OpenAI's tools. So kind of going back to packages, right, we've talked about this a lot at Sysdig, but there's kind of that, there are always going to be latent vulnerabilities in software packages. It doesn't matter what your use case is, you know, right now we're talking about AI, but there's a lot of libraries that will be reused to power AIs. So you're seeing some awareness now around common attack vectors against AI. I want to say at least one of them has called out kind of the vulnerable libraries that power that. You know, OWASP is very notorious for at least including one of those as their top 10. I can't remember if it's the AI top 10.

But if you have latent vulnerabilities in the packages that power your infrastructure and applications, well, then it inherits those vulnerabilities. So it becomes yet another attack vector. So for Sysdig, what we were seeing is kind of the adoption of those NLP engines, you know, natural language processing, large language models, generative AI packages,

like OpenAI has one that you would use to connect to OpenAI's platform. So what are we seeing amongst customers where they adopt that? And I believe the statistic was roughly 15%, right? Which is like, well, you know, you're hearing a lot more about it in media. Why aren't we seeing more? And it's kind of, you have to consider enterprise use cases and regulatory restrictions, right? And privacy laws, like how much data

do you actually want to offer an AI engine? Is that going to be open AIs, right? That could be intellectual property or sensitive data. I've seen some studies that also indicate that internal data is less valuable to AI than people would suspect. They've done comparisons of general purpose AI versus the highly trained internal data. And in what I was reading, it said that it was highly,

the general stuff outperformed massively how this stuff was going to work. When they wound up announcing Copilot for it could be trained in your internal code stores, my snide comment was, oh, great, they've taken a very clever robot and found a new way to give it brain damage by exposing it to your corporate code. And it's not inherently that wrong. It's- Well, Microsoft already saw it, right?

They equipped with the GitHub acquisition. But the terrifying part is, if you train it on your internal data and then start suddenly spitting that out verbatim to your competitors, that's a problem. Yeah, maybe it's wrong. Yeah, on some level, it's like, honestly, it's like, so what happens if a competitor comes in

and hires a bunch of our people? It's like, well, if I give you a subset of people, I honestly think we should just suggest it to them. I think that would be the neatest thing we could do to them because, yeah, that's unkind of me, but there are moments there where it's, everyone has to find their own path, and I think that stealing from competition

or appropriating stuff that isn't yours, which is a nice form of saying stealing, doesn't get you as far as you'd think. So in the couple minutes we have left, I'm curious to know anything else that jumped out at you from this version of the report. There's a lot of good stuff in here. It's very well done. It's beautiful, as always, good work. It inspires me of what some of my writing could look like if I worked a little more closely with a graphic designer. Yes, well, there's many minds that contribute to it. It is a very lengthy effort,

and I should give credit where it's due. Crystal Morin did a lot of work on this report. It's kind of primary authorship. But yeah, based on data and anonymizing it, then how do we surface those signals? Oh, and I want to call out as well, because as people know, they could buy my attention, but not my opinion. One of the things I've loved about this report, and I can't say about all reports that companies put out, it's not a thinly veiled sales pitch. It talks about the things that

your company solves for, because that's where you spend your time, energy, focus, thinking, et cetera. But it's not a collection of FUD. And the takeaway from the report is not, holy crap, I need to go buy Sysdig products now. Sorry if that was some marketer's plan, but that's not the approach. What it does take, what I do take away from it sincerely, is a sense that you folks keep your finger on the pulse of this stuff. You know what's going on. I am smarter now for having read this, and I recommend other people do too. It is not going to be a pulse of this stuff. You know what's going on. I am smarter now for having read this,

and I recommend other people do too. It is not going to be a waste of your time. Now, that said, what else is in the report that jumps out at you and got your attention? I was going to bring up a little bit of FUD, but it's kind of the reality, and we talk about this in the report, right? It's kind of the state of permissioning, right? Cloud entitlements, it's still not trending in the report, right? It's kind of the state of permissioning, right? Cloud entitlements,

it's still not trending in the right way. We're just not seeing organizations really scrutinize what are the appropriate permissions. And it's not just, you know, your employees or consumers that are in the cloud instance. It's also those services

or machine identities because they too also need to authenticate and authorize. Yes, that is not FUD. That is the grim reality of it. And I blame the cloud providers because I've done this myself. I had something that CodeBuild would build and deploy

and get stuff set up there. And it's still permissioned with admin access years later because I tried my darndest to do the responsible thing and it kept coming back with, nope, can't do it that way. And after six iterations, I'm the hell with it to do, uh, fix this. And that to do has been there for seven years. It's become load bearing at this

point. Yeah. And that's the reality, right? It's kind of like we, we preach about least privilege and you could say zero trust now, but it's very hard to do in practice. And the incentives are all wrong. If I overscope permissions, it might cause me problems in the future. But if I don't overscope the permissions, the entire thing does not work the future. But if I don't over scope the permissions, the entire thing does not work. And I have a problem right now in front of me. So I don't I don't castigate people for making those decisions. We all know it's not the right path. It's a shortcut. But it is so challenging to do it the right way that people don't. And yelling at people to be smarter does not work when it comes to security.

It has not worked for 50 years. So what are we going to do instead? Yeah, and it's tricky too, right? Because the guidance tends to be, well, enable, you know, 2FA on your accounts. It's like, well, maybe you could do that

for your employees. Would you do that for your customers? It depends how receptive they are to that. Like maybe they're not that tech savvy. They don't want to deal with a mobile. A lot of this stuff is one system talking to another, like, okay, great. I'm going to plug into it and then build a robot to push the button on a thing. Like that's just, that's just, it's extra steps.

Right. And that, that's kind of what I was getting to, right? You can't really do a multi-factor authentication the same way you would for machine identity. And you're talking about automation, right? It's like, well, nobody's going to sit there, turnkey, this service communication is blessed, allow it and plug in the YubiKey and then off it goes, right? You're talking about things like certificate-based authentication

or maybe it's behavior-based, like how is that service talking? Does it have a pattern of doing that or has it suddenly changed? So it's much more nuanced and way more complex. We're starting to see some regulatory language clarify what's needed and talk more about the service identities pieces of this. But it's an area that a lot of companies, it's tough. You hit the nail on the head. They're going to get the thing operational and then maybe it's on their list of to-do, right? We've seen that in some, not to name names, but we're seeing that in some complaints about

weak access controls. But this is how it happens, right? It's very easy to stand up the system, get it running. It's a lot harder to kind of do that in the most secure way possible when you think about all of your identities and how they communicate. There are no easy answers for this. And you wind up with OIDC and being able to pass information back and forth between providers, some of which don't support it. So it's, oh, just build long-term credentials and bake it into our system. Yeah, exactly. It's the hard code of password, right?

It's turtles all the way down. One of the reasons it's easier to stay single cloud is because at least there, in theory, you wind up with everything being aware of everything else it can talk to, whereas you've got to do a lot of extra work to integrate disparate services. Yeah. So with AWS, it seems like some of those services

don't talk to each other very well either, but that's a separate problem. Exactly, yeah. Does the service within the cloud even work with the secrets management solution, which AWS does have one, but are all of their services integrated fully? And then if you're a custom building something, does it also communicate the AWS secrets manager properly? It's a question mark for sure. Thank you for taking the time to speak with me. And if people want to grab their own copy of the report, they can grab their own at www.sysdig.com slash S-I-T-C. Thank you so much for taking the time. Last question before we wind up wrapping it.

What do you anticipate changing when we have this conversation a whole year away, which will go by at an eye blink in 2025? Yeah, very good question, Corey. You know, I would say the AI trends will increase. All right. I'd probably see some more adoption of packages as organizations experiment internally. Like, how can this support an enterprise use case and do that securely? I don't know if the identity piece will be fully addressed, but maybe we'll be more aware

of it. Maybe we'll see those numbers trend a little better, but there's going to be no shortage of kind of regulatory oversight of that, right? There's a lot of pieces that are going to start kicking in, certainly in the end of this year with EU's NIST 2 directive. But as things like the National Cybersecurity Strategy in the US get fleshed out and all the supporting acts,

these things are going to become incredibly important. So keep your eye on those things. Make sure you're securing, right? It's packages at the end of the day. It's containers. It's the things we know, you know, as engineers and security leaders. So the fact that it's an AI magic box

doesn't mean that the technology fundamentals changed or the security principles changed. It just means we need to make sure we're doing them in more places. I'm going to come back in a year and we'll find out. I'm looking forward to seeing how that bears out. I mean, go back two years ago,

AI was never on the roadmap. It was like, if you were talked about that, oh yeah, 10 years, it's always 10 years away. Kind of like cold fusion is always 20. Same story. Now, suddenly tomorrow becomes today and here we are.

Thanks for your time. My guest has been Mike Izbitski, Director of Cybersecurity Strategy 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 hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry, insulting comment that I will later delete because I'll have you next time.