Screaming in the Cloud - Sysdig and Solving for Strategic Challenges in Cybersecurity with Michael Isbitski

Episode Date: April 25, 2023

Michael Isbitski, Director of Cybersecurity Strategy at Sysdig, joins Corey on Screaming in the Cloud to discuss the nuances of an effective cybersecurity strategy. Michael explains that many companies are caught between creating a strategy that’s truly secure and one that’s merely compliant and within the bounds of cost-effectiveness, and what can be done to help balance the two aims more effectively. Corey and Michael also explore what it means to hire for transferrable skills in the realm of cybersecurity and tech, and Michael reveals that while there’s no such thing as a silver-bullet solution for cybersecurity, Sysdig can help bridge many gaps in a company’s strategy. About MichaelMike has researched and advised on cybersecurity for over 5 years. He's versed in cloud security, container security, Kubernetes security,  API security, security testing, mobile security, application protection, and secure continuous delivery. He's guided countless organizations globally in their security initiatives and supporting their business.Prior to his research and advisory experience, Mike learned many hard lessons on the front lines of IT with over twenty years of practitioner and leadership experience focused on application security, vulnerability management, enterprise architecture, and systems engineering.Links Referenced:Sysdig: https://sysdig.com/LinkedIn: https://www.linkedin.com/in/michael-isbitski/

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

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

and reduced latency. You can even ask users to reauthenticate SSH connections for that extra bit of security to keep the compliance folks happy. Try Tailscale now. It's free forever for personal use. Do you wish your developers had less permanent access to AWS? Has the complexity of Amazon's reference architecture for temporary elevated access caused you to sob uncontrollably?

With SIEM, you can protect your cloud infrastructure with customizable, just-in-time access workflows that can be set up in minutes. By automating the access request lifecycle, SIEM helps you reduce the scope of default access while keeping your developers moving quickly. Say goodbye to your cloud access woes with SIEM. Go to SIEMOPS.com slash Corey to learn more. That's S-Y-M-O-P-S dot com slash Corey. Welcome to Screaming in the Cloud. I'm Corey Quinn. I periodically find myself in something of a weird spot when it comes to talking about security. I spent a lot of my time in previous lives having to care about it,

but the word security was never in my job title. That's who my weekly podcast on the AWS Morning Brief and the accompanying newsletter goes out to. It's people who have to care about security, but don't have it as part of their job title. They just want to know what's going on without all of the buzzwords. This promoted guest episode is brought to us by our friends at Sysdig. And my guest is Mike Izbitski, Director of Cybersecurity Strategy at Sysdig. Mike, thanks for joining me. Thanks, Corey. Yeah, it's great to be here.

So you've been at Sysdig for a little bit, but your history is fascinating to me. You were at Gartner, which on the one hand would lead someone to think, oh, okay, you talk about this stuff a lot, but might not have been particularly hands-on. But that's not true either. You have a strong background as a practitioner, but not directly security-focused. Is that right? Yeah. Yeah, that is correct. I can certainly give the short version of the history lesson. It is true. Yes, as a Gartner analyst, you don't always get as hands-on, certainly talking to practitioners and leaders from all walks of life, different industries, different company sizes and organization sizes.

But yeah, as a Gartner analyst, I was in a different division that was much more technical. So for me personally, I did actually try to tinker a lot, set up Docker, deploy Kubernetes clusters, all that fun stuff. But yeah, prior to my life as an analyst, I was a practitioner and security leader for close to 20 years at Verizon. So I saw quite a bit and actually started as enterprise architect, building kind of systems and infrastructure to support all those business needs. Then I kind of transitioned over to application security towards the tail end of that career at Verizon. One of the things that I find that I enjoy doing is talking with folks in positions like yours, the folks who did not come to the cybersecurity

side of the world from a pure strategy advisory sense, but have been hands-on with these things at varying points in our careers. Just because otherwise I feel like I'm sort of coming at this from a very different world. When I walk around the RSA show floor, I am consistently confronted by people trying to sell me the same dozen products over and over again with different words and different branding, but it seems like it's all buzzwords aimed from security people who are deep in the weeds to other security people who are deep in the weeds, and it's just presumed that everyone knows what they're talking about already. And it obviously works. I'm not here to tell them to other security people who are deep in the weeds, and it's just presumed that everyone knows what they're talking about already.

And it obviously works. I'm not here to tell them that they're going about their business wrong, but for smaller companies, SMBs, folks who have to care about security but don't know the vernacular in the same way and don't have a sophisticated security apparatus at their companies,

it feels like a dense thicket of impenetrable buzzwords. Yes, very, very fair assessment, I would say. So I'd say my life as an analyst was a lot of lengthy conversations. I guess a little bit of the secret behind analyst inquiry. I mean, a lot of times they are hour-long conversations, sometimes multiple sets of them. But yeah, it's very true, right? There's a lot of nuance to how you work with technology and how you build things, but then also how you secure it.

It's very hard to condense that hours of conversation and many pages of documentation down into some bite-sized nuggets that marketers might run with. So I try to kind of live in that in-between world where I can kind of explain deep technology problems and business realities and kind of explain that in more common language to people. Sometimes that's easier said than done when you're speaking it, as opposed to writing it. But yeah, that's kind of where I try to bring my skills and experience. It's a little counterintuitive to folks coming at it from the other side, I suspect. But for me, at least, the hardest part of getting into the business of cloud cost optimization, the way that I do with the Duckbill Group, was learning to talk.

Where I come from a background that's heavy in the engineering and operations side, but being able to talk to business stakeholders who do not particularly care what a Kubernetes might be is critical. You have to effectively be able to speak to different constituencies, sometimes in the same conversation without alienating the rest of them. That was the hard part for me. Yeah, it's absolutely true. And I certainly ran into that quite a bit as an enterprise architect at Verizon. There's kind of really need to work to identify like what is the business need. And typically that is talking to the stakeholders, you know, what are they trying to achieve? They might not even know that, right? Because not everybody is very structured in how they think about the problem they're trying to solve and then what is their daily workflow.

And then you kind of arrive at the technology. I'd say a common fit fall for anybody, right? Whether you're an engineer or a security practitioner is to kind of start with the technology or the solution and then try to force that on people, right? Here's your solution to the problem. You didn't know you had. It kind of should work in reverse, right? What's the actual business need? What's your workflow? And what's the appropriate technology for that, right? What's the actual business need? What's your workflow? And then what's the appropriate technology for that, right? Whether it's right-sized infrastructure or

particular type of functionality or protection, all those things, right? So very similar kind of way of approaching the problem. It's just trying to solve for. I've definitely seen the kind of Kubernetes is all the rage, right? Or service mesh, like everybody needs to start deploying Istio and you really should be asking the question. It's all resume-driven development. Yeah, exactly. It's kind of the new kid on the block, right? Let's push out this cool new technology and then problems be damned, right? I'm only half kidding on that. I've talked to folks who are not running those types of things and they said that it is a bit of a drag on

their being able to attract talent. Yeah, it's newer technologies, right? So it can be hard to find them, right? Kind of unicorn status. I used to talk quite a bit in advisory calls to find DevOps practitioners that were kind of full stack. That's tricky.

I always wonder if it's possible to find them on some level. Yeah, and it's like, well, can you find them? And then when you do find them, can you afford them? Oh, yeah. What I'm seeing in this other direction, though, is people who are making, you know, sensible technology choices where you actually understand what lives where without turning it into a murder mystery where you need to hire a private investigator to track it down. Those are the companies that are having trouble hiring because it seems that an awful lot of the talent, or at least a significant subset of it, want to have the latest and greatest technologies on

their resume and their next stop which i'm not saying they're wrong for doing that but it is a strange outcome that i wasn't quite predicting yeah no it is very true i definitely see that quite a bit in tech sector i've run into into it myself, even with the amount of experience I have and skills. Yeah, companies sometimes get in a mode where they're looking for very specific skills,

potentially even products or technologies, right? And that's not always the best way to go about it. If you understand concepts, right, with technology and systems engineering, that should translate, right?

So it's kind of learning the new syntax or semantics, working with a framework or a platform or a piece of technology. One of the reasons that I started the security side of what I do on the newsletter piece, it caught some people by surprise. But the reason I did it was because I have always found that more or less security and cost are closely aligned spiritually, if nothing else. They're reactive problems, and they don't, in the general sense, get companies one iota closer to the business outcome they're chasing. But it's something you have to do, like buying fire insurance for the building. You can spend infinite money on those things, but it doesn't advance. It's all on the defensive reactive side. You tend to care about

these things a lot right after you fail to care about them sufficiently. Does that track at all from your experience? Yeah, yeah, absolutely. I was just kind of flashing back to some more stories at Verizon, right? It was, I'd say, very common that once you've kind of addressed, well, these are the business problems we want to solve for, and we're off to the races, right? We're going to build this cool thing. And then you deploy it, right? And then you forgot to account for backup, right?

What's your disaster recovery plan? Do you have logging in place? Are you monitoring the thing effectively? Are your access controls accounted for? All those tangential processes, but super critical. When you think about production general availability you need to be thinking about these things. And yeah, they almost always translate to that security piece of it as well, particularly with all the regulations that organizations are impacted with today. You really need to be thinking about kind of all these pieces of the puzzle, not just, hey, let's build this thing and get in on running infrastructure and we're done with our work. A question that I've got for you, because I'm seeing a very definite pattern emerging tied to the overall macro environment now, where after a 10-year bull run, suddenly a bunch of companies are discovering, holy crap, money means something again. Where instead of

being able to go out and get infinite money, more or less, to throw at an AWS bill, suddenly, oh, that's a big number and we have no idea what's in it. We should care about that. So almost overnight, we've seen people suddenly caring about their bill. How are you seeing security over the past year or so?

Has there been a similar awareness around that or has that not really been tied to the overall macro cycle very good question yeah so unfortunately security is often an afterthought right just like kind of those things that support availability probably going to get a little bit better ranking because it's going to support your customers and employees so you're going to get budget and headcount to support that. Security, usually in the pecking order, is below that, which is unfortunate because there can be severe repercussions with that, such as privacy impacts or data breach, lost revenue, all kinds of things.

But yeah, typically, security has been undercut. You're always seeking headcount. You need more budget. So security teams tend to look to delegate security process out, right? So you kind of see a lot of the DevOps programs, like can we empower engineers to run some of these processes and tooling and then security kind of become the overseer. So we see a lot of that where can we kind of have people satisfy some of these pieces. But then with respect to security budgets, it is often security tools consolidation. A lot of organizations tend to have a lot of things. So security leaders are looking to scale that back so they can work more effectively, but then also cut costs, which is definitely true these days in the current macro economic environment. I'm curious as well to see what your take is on the interplay between cost and security.

And what I mean by that is I did the numbers once. And if you were to go into an AWS native environment, ignore third-party vendors for a second. Just configure all of the AWS security services in your account, so the way that best practices dictate that you should, you're pretty quickly going to end up in a scenario where the cost of that outweighs that of the data breach that you're ostensibly trying to prevent. So it's an infinite money pit that you can just throw everything into. So people care about security, but they also care about cost. Plus, let's be very direct here, you can spend all the money on security and still lose. How do companies think about that now? A lot of leaders will

struggle with, are we trying to be compliant or are we trying to be secure? Those can be very different conversations and solutions to the problem. I mean, ideally, everybody would pursue that perfect model of security, right? Enable all the things, but that's not necessarily cost effective to do that. So most organizations and most security teams are going to prioritize their risks, right? So they'll start to carve out, maybe these are all our internet-facing applications. These are the business-critical ones.

So we're going to allocate more security focus to them and security spend. So maybe we turn up more security services to protect those things and monitor them. Then you unfortunately kind of end up with a glut of maybe internal applications or non-critical things that just don't get that TLC from security. Unfortunately for security teams, but fortunate for attackers, those things become attack targets, right? So they don't necessarily care how you've prioritized your controls or your risk.

They're going to go for the low-hanging fruit. So security teams have always struggled with that, but it's very true. Like in a cloud environment like AWS, yeah, if you start turning everything up, be prepared for a very, very costly cloud expense bill. Yeah, in my spare time, I'm working on a project that I was originally going to open source, but I realized if I did it,

it would cause nothing but pain and drama for everyone of enabling a whole bunch of AWS misconfiguration options, given a set of arbitrary credentials that just effectively try to get the high score on the bill. And it turned out that my early tests were way more successful than anticipated. And instead, I'm just basically treating it as a security vulnerability reporting exercise, just because people don't think about this in quite the same way. And again, it's not that these tools are necessarily overpriced. It's not that they aren't delivering value. It's that in many cases, it is unexpectedly expensive when they bill across dimensions that people are not aware of. And it's one of those, everyone's aware of the trap the second time

type of situations. It's a hard problem. And I don't know that there's a great way to answer it. I don't think that AWS is doing anything untow answer it. I don't think that AWS is doing anything on toward here. I don't think that they're being intentionally malicious around these things, but it's very vast, very complex, and nobody sees all of it. Very good point. Yes. Kind of cloud complexity and ephemeral nature of cloud resources, but also the cost, right? Like AWS is in the business of providing free service, right? Really, no cloud provider is. They are a business, right? So they want to make money on cloud consumption.

And it's interesting. I remember the first time I started exploring Kubernetes, I did deploy clusters in cloud providers so you can kind of tinker and see how these things work, right? And they give you some free credits, a month's credit to kind of work with stuff. And if you spin up a Kubernetes cluster, very bare bones, you're going to chew through that

probably within a day, right? There's a lot of services in it. And that's even with defaults, which includes things like minimal, if anything, with respect to logging, which is a problem, right? Because then you're going to miss general troubleshooting events, but also potential security events. So it's not necessarily something that AWS could solve for

by turning everything up, right? Because they are going to start giving away services. Although I'm starting to see some tides shift with respect to cybersecurity. The Biden administration just released their cybersecurity strategy that talks about some of this, right? Like, should cloud providers start assuming more of their responsibility and accountability, potentially just turning up logging services? Like, why should those be additional cost to customers, right? Because that's really critical to even support basic monitoring and security monitoring so you can report incidents and breaches.

When you look across what customers are doing, you have a different problem than I do. I go in and I say, oh, I fixed the horrifying AWS bill. And then I stop talking and I wait. Because if people light up at that, ooh, that's a problem for us, great, we're having a conversation. If they don't, then there's no opportunity for us, great, we're having a conversation. If they don't, then there's no opportunity for my consulting over in that part of the world. I don't have to sit

down and explain to people why their bill is too high or why they wouldn't want it to be. They intrinsically know and understand it, or they are honestly not fit to be in business. They can't make a strategic evaluation of whether or not their bill is too high for what they're doing. Security is very different, especially given how vast it is and how unbounded the problem space is, relatively speaking. You have to first educate customers in some ways

before attempting to sell them something. How do you do that without, I guess, drifting into the world of FUD, where here are all the terrible things that could happen. The solution is to pay me, which in many cases is honest, but people have an aversion to it. Yeah. So I mean, that's how I feel a lot of my days here at SysTick. So I do try to explain kind of these problems in general terms, as opposed to just how SysTick could help you solve for it. But,

you know, in reality, it is larger strategic challenges. There's not necessarily going to be one tool that's going to solve all your problems. The silver bullet, it's always true. Yes, SysTick has a platform that can address a lot of cloud security type issues, like over-permissioning or telling you what are the actual exploitable workloads

in your environment. But that's not necessarily going to help you with, you know, if you have a regulator breathing down your neck and wants to know about an incident, how do you actually relay that information to them, right? It's really just going to help surface event data, stitch things together that now you have to carry that over to that person or figure out within your organization who's handling that. So there is kind of this larger piece of governance, risk, and compliance, and security tooling helps inform a lot of that. But yeah, every organization has to answer to those authorities, often within their own organization, but could also be government authorities. Part of the challenge as well is that there's, part of it is tooling, absolutely. But an awful lot of it is a people problem, where you have these companies in the security space talking

about a variety of advanced threats of deeply sophisticated attackers that are doing incredibly arcane stuff. And then you have the CEO yelling about what they're doing on a phone call in the airport lounge. And their password, which is kiddie, by the way, is on a post-it note on their laptop for everyone to see. It feels like it's one of those, get the basic stuff taken care of first before going down the path to increasingly arcane attacks. There's an awful lot of vectors to wind up attacking an infrastructure, but so much of what we see from data breaches is simply people not securing S3 buckets, as a common example. It's one of those crawl, walk, run

types of stories. For what you do, is there a certain level of sophistication that companies need to get to before what you offer starts to bear fruit? Very good question. I'd start with, there's certainly an element of truth that we're lagging behind on some of the security basics or good security hygiene. But it's not as simple as like, well, you picked a bad password or you left the port exposed. Now, I think certainly security practitioners know this. I'd even put forth that a lot of engineers know it,

particularly if they've been trained more recently. There's been a lot of work to promote security awareness. So we know that we should provide IDs and passwords of sufficient strength. Don't expose things you shouldn't be doing. But what tends to happen is as you build modern systems, they are just extremely complex and distributed. Not to go down the weeds with app designs, with microservices architecture patterns and containerized architectures,

but that is what happens, right? Because the days of building some heavyweight system in the confines of a data center in your organization. Those things still do happen, but that's not typically how new systems are being architected. So a lot of the old problems still linger. There's just many more instances of it, and it's highly distributed. So the problem becomes very amplified very quickly. That's, I think, on some level, part of the challenge.

It's worse in some ways than even the monitoring and observability space, where, all right, we have 15 tools that we're using right now. Why should we talk to yours? And the answer is often, because we want to be number 16. It's one of those stories where it winds up just adding incremental cost. And by cost, I don't just mean money. I mean complexity on top of these things. So you folks are, of course, sponsoring this episode. So the least I can do is ask you, where do you folks start and stop? Sysdig, you do a lot of stuff.

What's the sweet spot? Yeah, I mean, there's a few, right? Because it is a larger platform. So I often talk in terms of full lifecycle security. A lot of organizations will split their approaches. They'll talk about shift left, which is really, let's focus very heavily on secure design. Let's test all of the code and all of the artifacts prior to delivering that thing. Try to knock out all quality issues for that general IT,

but also security problems, which really should be tracked all quality issues for that general IT, but also security problems, which really should be tracked as quality issues, but including those things like vulnerabilities and misconfig. So Sysdig absolutely provides that capability to satisfy that shift left approach, and Sysdig also focuses very heavily on runtime security or the shield right side of the equation, and that's give me those capabilities that allow me to monitor all types of workloads,

whether they're virtual machines or containers, serverless abstractions like Fargate, because I need to know what's going on everywhere in the event that there is a potential security incident or breach, I need all that information so I can actually know what happened or report that to a regulatory authority. That's easier said than done, right? Because when you think about containerized environments, they are very ephemeral. Container might spin up and tear down within minutes, right? And if you're not thinking about your forensics and incident response processes, that data is going to be lost. You're kind of shooting yourself in the foot that way. So yeah, Sysdig kind of provides that platform to give you that full range of capabilities throughout the lifecycle. I think that that is something that is not fully understood in a lot of cases. I remember a very

early Sysdig, I don't know if it was a demo or what exactly it was, I remember it was the old Heavybit space in San Francisco, where they came out, it was, I believe, based on an open source project then, that was still taking the perspective, isn't this neat? It gives you really in-depth insight into almost a system call level of what it is the system is doing. Cool. So what's the value proposition for this? And it's like, well, step one, be an incredibly gifted engineer when it comes to systems internals. It's like, okay, I'll be back in five years. What's step two? It's like, we'll figure it out then. Now the story has gone up the stack. It originally felt a little bit like it was a solution in search

of a problem. Now I think you have found that problem. You have clearly hit product market fit. I see you folks in the wild and many of my customer engagements, you are doing something very right. But it was neat watching. It's almost for me, I turned around, took my eye off the ball for a few seconds. And it went from, we have no idea what we're doing to we know exactly what we're doing. Nice work. Yeah. Yeah. Thanks, Corey. Yeah. And there's quite a history with Sysdig in the open source community. So one of our co-founders, Loris Dajani, was one of the creators of Wireshark, which some of your listeners may be familiar with. So Wireshark was a great network traffic inspection and observability tool. It certainly could be used by just engineers,

but also security practitioners. So I actually used it quite a bit in my days when I would do pen tests. So a lot of that design philosophy carried over to the Sysdig open source. So you're absolutely correct. Sysdig open source is all about gathering that syscall data, what is happening at that low level. But it's just one piece of the puzzle exactly as you described. The other big piece of open source that Sysdig does provide is Falco, which is kind of a threat detection and response engine that can act on all of those signals to tell you, well, what is actually happening? Is this potentially a malicious event? Is somebody trying to compromise the container runtime? Are they trying to launch a

suspicious process? So that those pieces are there under the hood, right? And then SysTick Secure is kind of the larger platform of capabilities that provide a lot of the workflow, nice visualizations, all those things you kind of need to operate at scale when you're supporting your systems and security. One thing that I do find somewhat interesting is there's always an evolution as companies wind up stumbling through the product lifecycle, where originally it starts off as we have an idea around one specific thing. And that's great. And for you folks, it feels like it was security. Then it started changing a little bit where, okay, now we're going to start doing different things. And I'm very happy with the fact right now that when I look at your site, you have two offerings

and not two dozen, like a number of other companies tend to. You do Sysdig Secure, which is around the security side of the world, and Sysdig Monitor, which is around the observability side of the world. How did that come to be? Yeah, it's a really good point, right? And it's kind of in the vendor space. There's also like chasing the acronyms and full disclosure, we are guilty of that at times, right? Because sometimes practitioners and buyers seek those things. So you have to kind of say, yeah, we check that box for CSPM or CWPP. But yeah, it's kind of talking more generally to organizations and how they operate their businesses. That's more well-known constructs, right? I need to monitor this thing or I need to get some security.

So lumping into those buckets helps that way. And then you turn on those capabilities you need to support your environment, right? Because you might not be going full bore into a containerized environment, and maybe you're focusing specifically on the runtime pieces, and you're going to kind of circle back on security testing in your build pipelines. So you're only going to use some of those features at the moment. So it is kind of that platform approach to addressing that problem. I would agree. I think that one of the challenges I still have around the observability space,

which let's remind people is hipster monitoring. I don't care what other people say. That's what it is, is that it is depressingly tied to a bunch of other things. To this day, the only place to get a holistic view of everything in your AWS account in every region is the bill. That somehow has become an observability tool, and that's ridiculous. On the other side of it, I have had several engagements that inadvertently went from, we're going to help optimize your cost to, yay, we found security incidents. I don't love a lot of these crossover episodes we wind up seeing, but it is the nature of reality where security, observability, and yes, cost all seem to tie together to some sort of unholy triumvirate.

So I guess the big question is, when does Sysdig launch a cost product? Well, we do have one specifically for... Oh, Bevance, once again, outpace me. But yeah, I mean, you touched on this a few times in our discussion today, right? There's heavy intersections, right? And the telemetry you need to gather, right? Or the log data you need to gather to inform monitoring use cases or security use cases. a lot of the times that telemetry is the same set of data. It's just you're using it for different purposes. So we actually see this quite commonly where assisted customers might pursue monitor or secure, and then they actually

find that there's a lot of value add to look at the other pieces. And it goes both ways, right? They might start with the security use cases, and then they find, well, we've over allocated on our container environments and we're over provisioning in Kubernetes resources. So, all right, that's cool. We can actually reduce costs that could help create more funding to secure more hosts or more workloads and environment, right? So it's kind of show me the things I'm doing wrong on this side of the equation, whether that's general IT or security problems, and then benefit the other. Typically, we find that because things are so complex,

yeah, you're over permissioning, you're over allocating, it's just very common. Kubernetes as amazing as it can be or is, it's really difficult to operate that in practice, right? Things can go off the rails very, very quickly. I really want to thank you for taking time to speak about how you see the industry and the world. If people want to learn more, where's the best place for them to find you? Yes, thanks, Corey.

It's really been great to be here and talk with you about these topics. So for me personally, I try to visit LinkedIn pretty regularly, probably not daily, but at least once a week. So please, by all means, if you ever have questions, do contact me. I love talking about this stuff. But then also on Sysdig, I do, sysdig.com, I do author content on there. I speak regularly in all types of event formats. So yeah, you'll find me out there. I have a pretty unique last name.

And yeah, that's kind of it. That's the, I'd say the main sources for me at the moment. Don't fall for the other Hizbizki. That's actually my brother who does work for AWS. That's okay. So there's no accounting for family sometimes. I kid, I kid. Great company, great work.

Thank you so much for your time. I appreciate it. Thank you, Corey. Mike Isbitsky, Director of Cybersecurity Strategy at Sysdig. I'm cloud economist Corey Quinn, and this has been a promoted guest episode brought to us by our friends at Sysdig. 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. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry, insulting comment from your place, which is no doubt expensive, opaque, and insecure, hitting all three points of that triumvirate. 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.