Subscribe
Share
Share
Embed
Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.
Transcript
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: 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, and uses that same key for SSH authorization and encryption. So basically you’re SSHing the same way that you’re already managing your network.
So what’s the benefit? Well, built-in key rotation, the ability to manage permissions as code, connectivity between any two devices, and reduced latency. You can even ask users to re-authenticate SSH connections for that extra bit of security to keep the compliance folks happy.
Try Tailscale now - it's free forever for personal use.
Corey: 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 Sym, you can protect your cloud infrastructure with customizable, just-in-time access workflows that can be setup in minutes. By automating the access request lifecycle, Sym helps you reduce the scope of default access while keeping your developers moving quickly. Say goodbye to your cloud access woes with Sym. Go to symops.com/corey to learn more. That’s S-Y-M-O-P-S.com/corey
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 Isbitski, Director of Cybersecurity Strategy at Sysdig. Mike, thanks for joining me.
Michael: Thanks, Corey. Yeah, it’s great to be here.
Corey: 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?
Michael: Yeah. Yeah, that is correct. I can certainly give the short version of the history lesson [laugh]. 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, a security leader for close to 20 years at Verizon so, saw quite a bit. And actually started as enterprise architect building, kind of, systems and infrastructure to support all of those business needs, then I kind of transitioned over to application security towards the tail end of that career at Verizon.
Corey: And 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 obviously worse. 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 sophisticated security apparatus at their companies, it feels like a dense thicket of impenetrable buzzwords.
Michael: Yes. Very, very fair assessment, [laugh] 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, kind of, condense that, you know, hours of conversation and many pages of documentation down into some bite-size 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 it’s easier said than done when you’re speaking it as opposed to writing it. But yeah, that’s kind of where I tried to bring my skills and experience.
Corey: It’s a little counterintuitive to folks coming out from the other side, I suspect. 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 of heavy on 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.
Michael: Yeah, that’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, [laugh] because not everybody is very structured in how they think about the problem you’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 pitfall 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 that maybe you didn’t know you had.” [laugh]. 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?
Whether it’s right-sizing the infrastructure or a particular type of functionality or protection, all those things, right? So, very similar kind of way of approaching the problem. It’s just what you’re trying to solve but [laugh] I’ve definitely seen that, 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—
Corey: Oh, it’s all resume-driven development.
Michael: Yep, exactly. Yeah. 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?
Corey: 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.
Michael: Yeah, it’s—you know, I mean, 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.
Corey: I always wonder if it’s possible to find them, on some level.
Michael: Yeah. And it’s like, well, can you find them and then when you do find them, can you afford them?
Corey: Oh, yeah. What I’m seeing in these other direction, though, is people who are making, you know, sensible technology choices where you actually understand what lives were 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 on 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.
Michael: Yeah. No, it is very true, I definitely see that quite a bit in tech sector. I’ve run 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.
Corey: One of the reasons that I started the security side of what I do on the newsletter piece, and 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. And you tend to care about these things a lot right after you failed to care about them sufficiently. Does that track at all from your experience?
Michael: Yeah. Yeah, absolutely. I’m just kind of flashing back to some war 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 [laugh], 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, kind of, tangential processes, but super-critical, right, when you think about, kind of, production systems, like, they have to be in place. So, it’s absolutely true, right, and it’s kind of definitely for just general availability, you need to be thinking about these things. And yeah, they almost always translate to that security piece of it as well, right, 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 it on running infrastructure and we’re done with our work.
Corey: 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 ten-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 gets 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?
Michael: Very good question, yeah. So unfortunately, security’s 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, right, which is unfortunate because [laugh] there can be severe repercussions with that, such as privacy impacts, or data breach, right, lost revenue, all kinds of things. But yeah, typically, security has been undercut, right? 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 DevOps programs, like, can we empower engineers to run some of these processes and tooling, and then security, kind of, becomes 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, like, security budgets, it is often security tools consolidation because a lot organizations tend to have a lot of things, right? So, security leaders are looking to scale that back, right, so they can work more effectively, but then also cut costs, which is definitely true these days in the current macroeconomic environment.
Corey: 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—
Michael: Yes.
Corey: 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?
Michael: A lot of leaders will struggle with, are we trying to be compliant or are we trying to be secure? Because 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. And 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 will be turn up 00:13:20] more security services to protect those things and monitor them.
Then [laugh], unfortunately, you can 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.
Corey: 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 that 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 untoward 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.
Michael: Very good point, yes. Kind of, cloud complexity and ephemeral nature of cloud resources, but also the cost, right? Like, AWS isn’t 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, like, 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 of credit 00:15:30], to kind of work with this stuff. And, you know, if you spin up a [laugh] Kubernetes cluster with 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 actual 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 tide shifts 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 the 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.
Corey: 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 [unintelligible 00:16:44] to that, “Ooh, that’s a problem 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’re honestly not fit to be in business if 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.
Michael: Yeah. So, that’s how I feel [laugh] a lot of my days here at Sysdig. So, I do try to explain, kind of, these problems in general terms as opposed to just how Sysdig can help you solve for it. But you know, in reality, it is larger strategic challenges, right, there’s not necessarily going to be one tool that’s going to solve all your problems, the silver bullet, right, it’s always true. Yes, Sysdig 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, you know, governance risk and compliance, and security tooling helps inform a lot of that, but yeah, every organization is, kind of, have to answer to [laugh] those authorities, often within their own organization, but it could also be government authorities.
Corey: 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 ‘kitty’ 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?
Michael: Very good question, right, and I’d start with… right, there’s certainly an element of truth that we’re lagging behind on some of the security basics, right, or good security hygiene. But it’s not as simple as, like, well, you picked a bad password or you left the port exposed, you know? I think certainly security practitioners know this, I’d even put forth that a lot of engineers know it, particularly if they’re 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, like, as you build monitoring systems, they’re 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 it, kind of, the—the problem becomes very amplified very quickly.
Corey: That’s, I think, on some level, part of the challenge. It’s worse in some ways that 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?
Michael: Yeah, I mean, there’s a few, right, because it is a larger platform. So, I often talk in terms of full lifecycle security, right? And a lot of organizations will split their approaches. We’ll talk about shift left, which is really, let’s focus very heavily on secure design, let’s test all the code and all the artifacts prior to delivering that thing, try to knock out all quality issues, right, for kind of that general IT, but also security problems, which really should be tracked as quality issues, but including those things like vulnerabilities and misconfigs. So, Sysdig absolutely provides that capability that 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, you know, 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.
And that’s easier said than done, right? Because when you think about containerized environments, they are very ephemeral. A container might spin up a 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 [unintelligible 00:23:10] [laugh]. 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.
Corey: 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 was the old Heavybit space in San Francisco, where they came out, it was, I believe, based on an open-source project and it 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?”
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 in many of my customer engagements. You are doing something very right. But it was neat watching, like, 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 of what we’re doing” to, “We know exactly what we’re doing.” Nice work.
Michael: 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 Degioanni, 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, you know, 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 sys-call data on 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 Sysdig 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.
Corey: 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 am 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?
Michael: Yeah, it’s a really good point, right, and it’s kind of in the vendor space [laugh], there’s also, like, chasing the acronyms. And [audio break 00:26:41] 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 checked that box for CSPM or CWPP. But yeah, it’s kind of talking more generally to organizations and how they operate their businesses, like, 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, right, 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 pipeline. 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.
Corey: Oh, 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, costs 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?
Michael: Well, we do have one [laugh], specifically for—
Corey: [laugh]. Oh, events once again outpace me.
Michael: [laugh]. 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 Sysdig 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 in an 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 security problems and then benefit the other. And yeah, typically we find that because things are so complex, yeah, you’re over-permissioning you’re over-allocating, it’s just very common, rights? 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.
Corey: 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?
Michael: Yes, thanks, Corey. It’s really been great to be here and talk with you about these topics. So, for me personally, you know, I try to visit LinkedIn pretty regularly. Probably not daily but, you know, 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, 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 Isbitski; that’s actually my brother, who does work for AWS.
Corey: [laugh]. That’s okay. There’s no accounting for family, sometimes.
Michael: [laugh].
Corey: I kid, I kid. Okay, great company. Great work. Thank you so much for your time. I appreciate it.
Michael: Thank you, Corey.
Corey: Mike Isbitski, 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 along with an angry, insulting comment from your place, which is no doubt expensive, opaque, and insecure, hitting all three points of that triumvirate.
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.