Jimmy Mesta: [00:00:00] Ideally, your application doesn't fire an alert at all. Things should just be silent, radio silent, if it's all working as planned. And then when something deviates from what we've established as good, then we're going to let you know. We shouldn't just be firing alerts because we don't know those are things we've imported into the tools. Resources aside, I would just go talk to developers and ask them at your organization once you write code, where does it go? If you just keep asking questions on the progress of code, you will find more than you'd like to know about, the inner workings of Kubernetes because at the end of the day, no two companies do it the same way.

Ashish Rajan: CSPM is not enough for Kubernetes security. There's a lot of gaps being left behind. Yes, that is true. If you are someone who probably is a CSPM right now, and you're probably giving some postural information, it is good, and I'm not discounting what you're doing is wrong.

All I'm saying is that, in this Kubernetes world that we're moving into, the more conversations that I have with people on what Kubernetes world looks like, where we're dealing with 10, [00:01:00] 000 clusters that's spread across the world. Like I'll take Starbucks as an example, where they have a container or a Kubernetes cluster deployed in each of their Starbucks cafe.

Can you imagine the number of clusters that are running and how they would do a updates and deployments to that? That is a scale of Kubernetes these days. And a simple security posture management sometimes may not be enough. So in this conversation with Jimmy Mesta from RAD Security, who is a returning guest to Cloud Security Podcast, he has written the OWASP top 10 for Kubernetes and has also been a trainer in this Kubernetes security space for a long time.

So we had the conversation with him about, Hey, what is really the gap? Like, why is it not enough for me to just look at my CSPM and see that as a thing that is solving my problem for Kubernetes and not just my cloud. We spoke about the difference between what a static misconfiguration look like in a CSPM world where we're focusing on the posture of the alerts we're finding, and perhaps not all of them required to be immediately actioned on.

Perhaps need some focus on runtime, especially if you have a complex Kubernetes first world that you're looking at. [00:02:00] I hope you enjoyed this conversation with Jimmy. He's got a lot of knowledge in the Kubernetes space and the Kubernetes security space. I've been trying to study and become a lot more Kubernetes aware in the last couple of years and have started doing training in Kubernetes security over the past year or so.

I'll tell you there's so much complexity around that I sometimes feel that just like one year, two years is not enough. But at least I'm hoping this conversation that I have with Jimmy and all the other content we create on Cloud Security Podcast YouTube channel would give you enough information as a security person to start talking more in an educated way about what Kubernetes security could be in the cloud native world that we are all moving towards, especially if your organization has decided to go container first and Kubernetes first for all new workload. If you know someone else who's probably trying to tackle the Kubernetes security problem, definitely share this episode with them. If you are that person, I hope you enjoy this episode as well.

If you're here for a second or third time, I would really appreciate if you're watching this on YouTube or LinkedIn, definitely give us a follow subscribe. It definitely means a lot that you are supporting us there, but if you are listening to this on Apple, iTunes or Spotify, give us a five star rating and I will really appreciate the follow as well because it really helps [00:03:00] spread the word of the awesome Kubernetes security work we're doing as well to educate more people about the complexity and the nuance that Kubernetes security is bringing as well.

I hope you enjoyed this episode of Jimmy. I'll see you in the next episode. Welcome to Cloud Security Podcast. On Air Now. Welcome to the show again. Could you share a bit about yourself, Jimmy?

Jimmy Mesta: Thank you for having me. I know we've got to hang out a lot reintroduction. I'm Jimmy Co Founder and CTO of Rad Security. I've been working in security, AppSec, infrastructure, CISO, Compliance little bit of everything for about 16 years.

Fun fact, I have one of the first degrees from Penn State in cyber security. We were guinea pigs and so I actually have a degree in that. And it looks nothing like today. Started RAD a little over two years ago and we're out to solve all the world's problems of behavioral cloud native security

Ashish Rajan: What is cloud native security for people who probably are confused by their own definition of cloud native security?

Jimmy Mesta: Yeah, it's a confusing time. We're at RSA right now Which means there's no shortage of marketing cars [00:04:00] AI etc. For us really comes down to, getting as close to the workload and source of truth and real time as possible. We started the company and the product on the premise that you cannot just scan your environment once a week or once a day and hope that you've caught all the things.

And we've built a lot of tooling and capabilities, some of it's eBPF, some of it's real time Kubernetes logs, cloud, metadata, things like that, and we surface risk that's contextualized with, cloud native in mind.

Ashish Rajan: So would you say cloud native is almost like having elements of Kubernetes?

What the cloud has to offer because you've mentioned cloud metadata as well. All of that combined would be how would you define in 2024, with a sprinkle of AI?

Jimmy Mesta: Yeah, a little bit of AI. Yeah. It's using cloud APIs to their fullest extent, but it's more importantly building your applications to leverage those, right?

Containers are, an application packaging mechanism. Most of our customers, their containers are [00:05:00] cycling and rebuilding every five minutes or less. And you. are leveraging, tools like RDS inside of AWS, IAM all of those native APIs built together, stitched to make an application stack that's more native to the environment that it's in.

Ashish Rajan: To add to what you were saying as well, in terms of how workload security or security in general has been approached on premise, and I guess even 2024, we have people moving into the cloud, people moving to cloud native directly. Still moving. Yeah. Containers, Kubernetes, all of that. How's cloud native different to what people have done in traditional environments?

Jimmy Mesta: Traditionally we and I used to use all the classic IDS IPS tools, right? And you think about that model where you are maintaining writing and using signatures to look for very specific events that happen inside an environment. It worked okay then. And then you introduce ephemeral environments and the cloud native APIs and just in time access and all these things that just move at the speed of light. [00:06:00] The signature based approach is something that folks try to reapply to cloud and then fall flat. That doesn't really work super well. So we've built a lot of things to combat that and get out of that cycle of just building signatures that need tons of maintenance.

Ashish Rajan: We were talking about how things were done traditionally. IDS IPS relies on the whole signature aspect of it. Yeah, okay, if I see a signature, that's a bad signature. Okay, Ashish, there's an alert for you. Yeah, someone should investigate this. You're saying it needs to be different in 2024?

Jimmy Mesta: We believe so.

Ashish Rajan: Like how different are we talking?

Jimmy Mesta: Our kind of thesis and what we've built into the product is behavioral baselining. So if you think of your cloud native ecosystem as, a population of humans, each of them having unique DNA sequences that, define who they are, we do that automatically and constantly in real time, and then tell you when something's up when we're out of that kind of standard baseline operating procedure, we classify that as drift and then we [00:07:00] analyze those drift observations, and then we can surface things that a signature could never catch, right? Because there's a precedent for some attacks, right? There are zero days. There are evasions. There are suspicious users. So you need to understand what's good before you can actually deem something dangerous.

Ashish Rajan: Do you add to what you were saying as well? So in terms of Putting what you mark as a behavioral thing. A lot of people normally, when they think about cloud and cloud native, they're like, Oh, CSPM. I have a CSPM, man. Why would I care about this? Yeah. And where is the line drawn? To be honest, I think because you mentioned eBPF in the beginning as well.

Yep. A lot of people may not even know what eBPF is. So maybe just to set the context for people who are maybe perhaps new to the cloud native space. What is eBPF?

Jimmy Mesta: Yeah, eBPF is a collection tool, right? It's a utility that you can use to instrument the lowest level of a workload, right?

Yeah. Kernel. So when a container starts or an operating system starts, it [00:08:00] exhibits certain behaviors. It spawns a process, it creates a network connection, and it's fairly predictable once you learn that. eBPF is a really performance safe way to get that data in real time out of the kernel and into a better format for security responders.

CSPM doesn't use eBPF because it really just is all about checking a box of am I configured correctly from a cloud standpoint, or my database is exposed to the internet. Do I have a load balancer that You know, has some sort of misconfiguration, is my S3 bucket exposed. Those are important hygiene tasks not to discount, why we need that, but it really doesn't help you stop a breach.

It doesn't help you detect a supply chain attack, a zero day attack, a suspicious user. It's not a real time representation of what's going on from a workload perspective. They can work together. Our platform does have elements of posture that are combined with real [00:09:00] time eBPF style telemetry. And that's important, but I think if you just rely on a CSPM and call it a day, you're missing quite a bit, to say the least.

In the cloud native space. In the cloud native space.

Ashish Rajan: And worthwhile calling out, eBPF is part of that whole Kubernetes ecosystem, which has been there for a while. It's supposed to be like that, almost like a network level thing that you can talk about. And to your point about making API calls, and I want to double click on that for a second, Cause I think a lot of CSPM call out that, hey, we can look at Kubernetes inside. Sure. And a lot of people are building AI workloads and their normal workloads are moving into containers and Kubernetes as well. Why is it not enough to just do API? Why would I care about the eBPF part when I just can do API calls to my AWS or Azure?

Jimmy Mesta: Yeah, so AWS exposes many APIs to valid users, operators, et cetera, and security tools. And you can understand mostly static configuration. There are logs [00:10:00] you can gather. Logs are important. They do tell some of the story, but when you really want to detect something like the XZ, backdoor, right?

That is a pretty classic example of something that wasn't a CVE. It wasn't a misconfiguration. Yeah, it's a. suspicious maintainer that's pushing code out to the world. It's pretty gnarly. And you're not going to be able to just interrogate your AWS API and ask am I affected by this? And there's not really an end point for that.

You have to understand, first of all am I dealing with a known vulnerability or not?

Ashish Rajan: Yeah.

Jimmy Mesta: And then what is my workload expected to be doing? Cause XZ had a lot of behaviors that were not expected, right? There's reverse shells. There's all sorts of things that are very detectable when you understand what's good?

And then if maintain an eBPF Implementation that's watching those lower level system calls You're going to be better equipped than just looking at APIs because they're not going to tell you the whole story

Ashish Rajan: Where we said with IPS , IDS and on premise world It's [00:11:00] like similar capability using eBPF.

You can be right next to a container inside your Kubernetes cluster to be able to see a bit more deeper level security rather than, hey, is my cluster API console open to the internet? Yeah. Like a bit more deeper than that.

Jimmy Mesta: It's hardening versus detection, right? Where CSPM is going to help you get to a point where you can, maybe have a more secure, hardened environment.

And that's good. But the most hardened environments still have breaches, right? Things slip through the cracks. And I think more teams in 2024 are leaning towards detection and response. Almost like we're shifting right again after we yelled about shifting left last year, and then we'll shift somewhere else.

But it's important to really maintain that runtime security observability and response, given the nature of the workloads we're dealing with.

Ashish Rajan: Yeah, but runtime security has always been looked at as a place, there's a lot of false positive, and very few true positive.

Alert fatigue is a real [00:12:00] thing. Yeah. A lot of people get a little tons of alerts. Red wall is like a very common term people keep talking about. Oh, every time I turn it on, there's a wall of red that I'm looking at. I can't look at all of them. What do you think is the right way to approach the whole thing?

How do I separate the signal versus noise so I can focus more on the true positive?

Jimmy Mesta: That's the, not million dollar question, billion cybersecurity. Alerts are a side effect of signatures that are trying to be a one size fits all solution. If you think about 99 percent of security vendors or tools.

You sign up and then you have a hundred rules that they give you, right? And they're like, these are your hundred rules, but they're also for this other company. Yeah, and everybody gets the rules like Oprah Winfrey show, like y'all get a, y'all get a rule. Oh, y'all get a rule. And I think that without the nuance of your environment and understanding what's running and what's important to you, I'm tailoring those observations, right?

Not just findings or alerts. If you don't do that, you're going to be sifting through things that are irrelevant and then doing triage, right? [00:13:00] Again, you're just triaging findings, alerts, et cetera, for us. And our big bet is really let's learn and baseline what is good. And. Ideally, your application doesn't fire an alert at all.

Things should just be silent, radio silent, if it's all working as planned. And then when something deviates from what we've established as good, then we're going to let you know. We're going to analyze the drift. We're going to classify it and do our best we can to give you the information about it.

But we shouldn't just be firing alerts because those are things we've imported into the tools. It's a different approach. I think it is what detection teams want, but haven't built yet. And we're out on a mission to get it out there and get the feedback, getting comfortable with the quiet.

Ashish Rajan: Yeah.

Jimmy Mesta: Yeah.

Ashish Rajan: That is literally, and that's probably like the worst nightmare for a detection team. Like I haven't had, yeah, I haven't had alert for hours. Maybe also to add another layer to this as well for all the cybersecurity leaders and CISOs who are listening to this [00:14:00] conversation in terms of where you find the challenges for people as they migrate.

Like we spoke about challenges from moving from on premise to cloud, how none of that stuff works. Now we are on that journey for a lot of people who are probably already in cloud. Moving to cloud native because the directive from the organization is that, Hey, moving forward, Kubernetes containers, nothing else.

Only by exception, you go back to virtual machine. Otherwise you're going via that. This is the future. What are some of the challenges for security perspective you're seeing people have and maybe perhaps some ways on how they're tackling it as well.

Jimmy Mesta: There's so many challenges. I think there's a big disconnect between infrastructure folks and software developers.

There's a very different community and objectives, right? A software developer, is going to be working on a team with a product manager that says, we need this feature next week. Yeah. Great. Fine. Infrastructure teams want to make sure everything's up and running, reliable, etc. Security teams are trying to straddle between the two, but probably not getting through to [00:15:00] either of them.

And I think the big challenge is how do we enable developer efficiency to leverage things like Kubernetes, like containers, like these are very powerful technologies that can help you move really fast.. Yeah. But also, like, how do we keep them on the rails, right? How do you make the path the happiest of paths for a container to ultimately come from a developer's laptop through a pipeline and then into a production environment that's safe?

Again, we believe that if you can baseline what is good, a developer can also change the behavioral fingerprint if they need to, right? Yeah. That artifact can, similar to how you would think about like an SBOM, right? An SBOM is just a, it's well structured manifest that has packages, libraries, versions, but that's it like at rest, right?

If you think about a runtime bill of materials, not that's what we've built necessarily, but it's. What happens when it runs, right? It doesn't look like an SBOM so I think developers can understand that. So I think being [00:16:00] proactive is the theme for 2024 for us, is let's draw a line in the sand and then be proactive about it, because reactive security isn't really working for us right now.

Ashish Rajan: What would be an example of a proactive security?

Jimmy Mesta: I think, so in, a developer building a new feature, let's say , they're importing a new library, that library needs to call out to some external IP address to download a file.

Ashish Rajan: Yeah,

Jimmy Mesta: Fine, right? Maybe that's what the application needs to do the developer should pre define that behavior before they even ship it that way when it's at runtime, there's no alert.

There's nothing we expected that to happen but at runtime if all of a sudden the application calls out to some IP address that's completely out of the spec that the developer defined that's drift, right? That could have been, a supply chain attack. Somebody could have tampered with something in the CICD pipeline.

There's no signature that's ever going to find that. It's literally just predefined profiles and baselines that [00:17:00] dictate your runtime security later.

Ashish Rajan: Out of curiosity, who's looking at the Kubernetes. We were having this conversation some time ago, and we're talking about the fact that a lot of the cloud alerts were going to vulnerability management teams, not to SOC.

And now there's this transition from vulnerability to SOC. I feel to what you were saying as well. People who are moving in and this is more for the leaders as well. There was a shift of confusion when who's going to own alerts from cloud. Yeah. And now there's Oh, we have cloud native as well.

Who's going to own alerts from cloud native. All this Kubernetes capability we're building, which is in AWS or Azure or Google cloud, but looks and feels very different to what we've been doing in cloud in general with virtual machines. Is there a shift happening there as well in terms of who's looking after this on the other end?

Jimmy Mesta: We've been watching this like title of detection engineer. And it's not, SOC is involved. These are engineers on the security team that deal with codifying and distributing detections, right? That's a very growing field. I think there's a lot of people [00:18:00] hiring there. But the alert side is a bit of a hot potato thing.

Like I don't want it. You don't want it. It's Kubernetes. So no one wants it. Like it's it becomes very tricky. So it's easier to put your head in the sand and ignore it. But again, the idea is let's not just keep generating alerts for the sake of it. Cause I feel like we're building like, it's a really bad sort of muscle memory. It's all a thing. I just have a flood of alerts. That's what I do. I'm an alert mitigator. Let's focus on maintaining and curating a registry or a catalog of what's good. I feel like that's where security teams should be headed, not towards like, where can I route my alerts?

Oh, yeah. That's just that's really dangerous because things will slip through the cracks and alert fatigue eventually results in missing attacks. Yeah. Because things are flying by the screen. You keep clicking ignore. It's like your email inbox, right? There's certain things you don't even see anymore.

Because they just fly by every single day. That's right. Maybe it's important.

Ashish Rajan: Yeah, we spoke about CSPM [00:19:00] not being enough because API calls are not enough in this cloud native Kubernetes world. Is there a solid example that comes to mind that would not be, and I'm obviously generalizing quite a bit by calling out every CSPM and how they do Kubernetes, but are there obvious things that you feel is a gap in the current way people do CSPM and when compared to Kubernetes So I think the distinction is like how different can the alert be is usually and I feel like sometimes it's just because of the lack of knowledge about how almost like a data center that you're running with Kubernetes sometimes that this is whole full on there was a talk that I came across, they're doing multiple applications in one cluster, I thought that used to be the anti pattern, but now it's like becoming a pattern, because after a certain scale, you apparently have to do that, I'm like, oh, wait, we're on that stage already where initially we said we should not have more than one application on one node, now we have multiple applications on one node now, so what's going on there?

So are there any example that comes to mind where it would help people get crystal clear on, Oh, if I see this, that's a very Kubernetes [00:20:00] specific thing. I know I am putting you on the spot.. But if there anything that comes to mind.

Jimmy Mesta: If you look at the acronyms and the definitions like cloud security posture management, right?

Those are to me, not really alerts. They are recommendations provided by a tool that has some context into your cloud taken as a snapshot that you can prevent something catastrophic from happening potentially, right? Yes, it's right. That's all you're trying to do So to me those are longer term projects that are typically you don't get an alert and fix it in the middle of the night like your CSPM is just gonna have some posture stuff.

Yeah, something's important and other stuff Yeah, no, I'm not gonna deal with that. Yeah. Yeah, so it's like a day a different team, a different model, I would tie that to almost like you have a Jira Epic that comes out of that alert, versus at runtime time is, time is important where you have, you're seeing malicious behavior, like somebody is on the box doing something they shouldn't.

You have to act like really fast or you're in a world of hurt. [00:21:00] Those types of alerts should be routed through different channels. Different teams deal with them, right? That's a 24 by seven coverage team. Automation is really important. If you see certain patterns, kill the pod, do whatever.

So I just think they're completely different animals. And I don't think a CSPM saying they do all of Kubernetes security, it just cannot cover it. You could do some posture, simple stuff, sure, but you're not routing those to the same individual.

Ashish Rajan: Is there a definite example that comes to mind in the Kubernetes world that you may have?

Because you've been doing Kubernetes training for a long time as well.

Jimmy Mesta: Yeah. And we offer Kubernetes posture inside of our product, but it's, we have a unique spin on it. Because again, I have this belief that findings don't live in isolation. Misconfigurations aren't just, It, especially in Kubernetes, they aren't just one thing and then like you go fix it and everything's solved.

It's a graph problem, right? The misconfiguration has these other elements of risk and it has network connectivity and it's in a production cluster. And, you go down the list. So the [00:22:00] biggest thing is can you take all of that data and show less to the responder, but with more context and more fidelity.

Yeah. And that's the challenge that we're up against, in Kubernetes, things change very frequently. Yeah.

Ashish Rajan: I think the other challenge that come to mind for me has been, as I've gone deep dive into the Kubernetes world over the past couple of years, when I was transitioning to trying to learn more about Kubernetes, in my mind, I was like, Oh, I know about API, the clusters, the node security, or container in terms of images and all of that.

Yeah. Then I got introduced to this world of the more conversations I had, the more people like, Hey, are you guys using Istio? Are you using eBPF? There are all these other service mesh is another one. Network plugins. Yeah. A lot of plugins. And I'm like, wait, so Kubernetes by itself is not enough. There's all these other open source things that have been plugged into it.

Yeah. I don't know if the CSPM can look into all of those as well. Or when they look at the posture, they look into those as well. Because that is a, to what you said earlier, in a posture game, it's a context of oh, I'm just looking at API calls from a cloud [00:23:00] provider, but it doesn't matter which cloud.

In the Kubernetes game, if I just make the Kubernetes API call, Where I still get information about Service Mesh, Istio, and all of that I'm using as well, that I've misconfigured it, or not using the right way.

Jimmy Mesta: You'll get information, right? You'll get the Istio, for example. You'll get the namespace, Istio system namespace.

You'll get the containers that are running. You'll understand how it's configured at a high level, but you will not understand if Istio itself is a target for an ongoing campaign, or I used to do red team assessments and we would always, the best backdoor in Kubernetes is to just put your payload in the Istio namespace or the kube system namespace, call it like the Istio controller, YAML file. Like no one will touch it. Cause they're like, I don't know how Istio works. So I'm just like, I'm going to leave that there. And you can have a backdoor running for a year if you want it. No, one's going to ever touch it.

I think those projects are very complex. Istio itself. The install is probably like 5, 000 lines of YAML plus a bunch of [00:24:00] RBAC, a bunch of network stuff, host stuff. It's privileged. Like it's absolutely crazy, but we just accept it and we install it with helm and call it a day. Yeah, so Somebody's got to watch the watcher in that case.

Ashish Rajan: Yeah and maybe hopefully they can use your OWASP top 10.

Yeah,

Jimmy Mesta: it's a good start If you're trying to get started and like just wrap your head around the basics, I think that's what it's there for It's also getting pretty widely adopted. It's something to check out.

Ashish Rajan: Yeah, because that's where I was coming from.

So people who are watching or listening to this, now that we understand there's a bit more complexity than just finding out what my CSPM was telling me, all these other things that I need to be looking out for, whether it's run time or on the deployment time are there any resources and what kind of skill set should the red teamers or SOC team be thinking about when looking at now that we're moving into that Kubernetes first world. Yeah. What kind of skill sets should they be looking at and are they good resources that you can recommend?

Jimmy Mesta: Yeah, the top 10 is a good start. There are resources embedded in it. So obviously I'd point people to that. I think it's moving really fast.

So [00:25:00] resources aside. I would just go talk to developers and ask them at your organization like, once you write code, where does it go? How is an image built? Where is your registry? If you just keep asking questions on the progress of code You will find more than you'd like to know about, the inner workings of Kubernetes because at the end of the day, no two companies do it the same way.

Everybody's deploying stuff and it's all snowflakey and it's all very which wasn't what we were supposed to do with containers, but it's very unique. Our customers all run Kubernetes very differently, right? Starbucks runs one in every single Starbucks. Yeah. Wow. It's that's a thing. And that's a much different challenge when you're dealing with 10, 000 clusters versus 10, 000 nodes versus 10, 000 pods.

And like, how do you get upgrades and patches out? And like, how do you change all these things. So it's really fascinating, but I wouldn't, like there are certain skills and those can probably be taught, but I would literally just do an, Sherlock Holmes your SDLC. And cause I don't think most [00:26:00] people know how their software ultimately runs.

Yeah, I do it in a friendly way, not in a, I'm auditing you. Yeah, you don't have to have a, yeah, like a pipe and not an audit. Just just be curious. Yeah.

Ashish Rajan: Yeah. And to, just to understand the complexity of the world that your fellow developers are coming from as well. Yeah.

Jimmy Mesta: Everyone's got everyone's got struggles.

Ashish Rajan: Do you feel that with the SOC teams, do they have to be upscaling Kubernetes as well?

Jimmy Mesta: I think so. Yeah. If you get an alert in the middle of the night and. It's gonna be in a cluster, you're gonna have to understand the context of how that workload's running, right? Yeah. To some degree. Because your alert could say hey, there's a service account that's being used to access the Kubernetes API.

If you don't know what Kubernetes is or how it works, you're going to not really know how to respond to that. Or even where to start. Yeah, and until AI takes over all of our jobs, then you know, we're going to have to learn this.

Ashish Rajan: Because to be fair, we haven't even gone into the whole managed Kubernetes versus self hosted Kubernetes as well.

Yeah. That's another, for people who have been in the Kubernetes space for a while, they've been using self [00:27:00] hosted for so long that they're not going to get rid of it. Yeah, but then we have this new wave of managed Kubernetes.So depending on where you land, you may be in a completely different kind of Kubernetes environment to what other people may be like, super, even more customized or really old or yeah, there's a few versions old, to your point that people ask questions like, Oh, what version of Kubernetes did you get introduced to Kubernetes then?

Yeah. It's some sort of marker on your journey. Yeah. Like to the point that, Oh, there's that dramatic a difference between Kubernetes versions as well. So which Kubernetes version do you land on or people have used is very different because even in the managed case, you have to pick what version of Kubernetes you're going for as well.

Yeah. And they only support a certain amount. Yeah. Oh my God. It's like the complexity that comes with it is I thought cloud was complicated.

Jimmy Mesta: You throw Istio in the mix and that has the same versioning problem. It's like another whole separate area.

Ashish Rajan: On that complex note, we should probably call it a day.

Yeah. Yeah, obviously I do these three questions that you have been well aware of. Yeah. So the first one being what do you spend most time on when you're not working on [00:28:00] solving runtime Kubernetes challenges.

Jimmy Mesta: I have two boys at home and I try to spend as much time with them as I can, riding bikes playing outside, trying to be a good dad while also a good dad and husband while starting a company.

So yeah that's my hobby. Ride a lot of bikes too.

Ashish Rajan: So just trying to keep a calm with the chaos going around here with startups.

Jimmy Mesta: These days. Yeah. Yeah. Yeah. Fair. We have one that's getting in the chess right now and I'm, which is really cool to see. Oh wow. Okay. Yeah. Yeah. Tough competition there, man.

That's a boy genius, yeah.

Ashish Rajan: Second question. What is something that you're proud of that is not only social media?

Jimmy Mesta: We did get a top 10 finalist for the RSA innovation sandbox this year. Yeah, that's where I just came from. Yeah but other than that, yeah, I was a nationally ranked BMX racer as a child.

As a child? Yeah until I was 12. I yeah, I raced it like, you know across the country and yeah. At 12? Oh, wow

Ashish Rajan: I was going to say, definitely, that's why RAD, I can totally see like a BMX, I mean I can totally see a BMX brand and a RAD brand, I can already see [00:29:00] how they would go together as well.

Exactly. Third and final question. Favorite cuisine or restaurant? I'm assuming it's coffee. Coffee, yeah.

Jimmy Mesta: Just caffeine. Caffeine pills. Favorite cuisine as of late is probably at a restaurant, still, I mean it's Thai. I just like Thai food. Yeah. Yeah. I think it's like. It's everywhere. I like ramen too.

If I travel anywhere, I try to find the best ramen I can, and that's been a thing for years. Any good in SF ramen? Probably, but I can't think of it off the top of my head. And usually, yeah, I've done Momofuku in New York. Oh, yeah. The ramen bar there, yeah. I've done a bunch of places. Taiwan, all over, yeah.

Ashish Rajan: Oh, wow, yeah. You're like traveling for ramen.

Jimmy Mesta: Travel

Ashish Rajan: for

Jimmy Mesta: the ramen.

Ashish Rajan: Where can people find you on the internet? Especially know about the whole innovation sandbox that you guys got the top ten finalists, right?

Jimmy Mesta: Yeah. Brooke, our co founder, just presented. It was amazing.

It was like a thousand people there. I'm jimmy@radsecurity. LinkedIn is It's probably the easiest though, or Twitter.

Ashish Rajan: Yeah. I'll put [00:30:00] those things in there. I was like, is it the rad Jimmy? It could be like, Oh, Jimmy the rad. But dude, thanks so much for coming on the show, man. I really appreciate this.

Always a pleasure.

Thank you for listening or watching this episode of Cloud Security Podcast. We have been running for the past five years, so I'm sure we haven't covered everything cloud security yet. And if there's a particular cloud security topic that we can cover for you in an interview format on Cloud Security Podcast, or make a training video on tutorials on Cloud Security Bootcamp, definitely reach out to us on info at cloudsecuritypodcast. tv. By the way, if you're interested in AI and cybersecurity, as many cybersecurity leaders are, you might be interested in our sister podcast called AI Cybersecurity Podcast, which I run with former CSO of Robinhood, Caleb Sima, where we talk about everything AI and cybersecurity. How can organizations deal with cybersecurity on AI systems, AI platforms, whatever AI has to bring next as an evolution of ChatGPT, and everything else continues.

If you have any other suggestions, definitely drop them on info at CloudSecurityPodcast. tv. I'll drop that in the description and the show notes as well, so you can reach out to us easily. Otherwise, I will see you in the next episode. [00:31:00] Peace.

‍