Shauli Rozen of ARMO

Jeremy at Firetail (00:03.278)
Welcome back to another episode of the Modern Cyber Podcast. I am your host Jeremy coming to you back from my dungeon lair after fwd:cloudsec where we had the opportunity to record with a number of guests live. We're back to our usual gig and we're talking to somebody who has been in the cloud security space for a while, working on a very particular problem space. I am really excited to be joined by Shauli Rozen, founder and CEO of Armo, the company behind the popular open source Kubernetes security platform Kubescape.

Shauli is an open source advocate and security expert, a frequent speaker in cloud native conferences such as Cloud Native Security Con, DevSecCon, and DevOps Days. Shauli holds a BS in communication systems engineering from Ben Gurion University and an MBA from the Wharton School at Penn. He's also an avid surfer, so you can always find him in the ocean at 5 a if the conditions are right. Before we got on, unfortunately, he told me the conditions were not right today, so he didn't have a chance to surf. I don't know if that's gonna put him in a bad mood for today's conversation. I hope not.

But Shauli, thank you so much for taking the time to join us today.

Shauli Rozen (01:06.529)
Thank you for having me. And you've made my mood better now.

Jeremy at Firetail (01:11.437)
Okay, awesome, awesome. Yeah, there'll be waves tomorrow. Let's hope so. But I wanna start by talking about Kubescape. First, I just wanna give you an opportunity to tell people what it is. I've heard the name. I will admit, I come from a cloud security background, but I'm no Kubernetes security expert. So explain to us what Kubescape is and what are the problems that it's solving.

Shauli Rozen (01:15.841)
Exactly.

Shauli Rozen (01:33.697)
Yes, well, I will start by saying it's actually.

You know, what you just said is very interesting. You know, I come from a cloud security background, but I'm not a Kubernetes expert. In my mind, those two are converging really, really, really fast. And, you know, cloud security and Kubernetes expertise are becoming more and more intertwined. You know, I consider myself a cloud security company that has the best solution for Kubernetes first companies, right? But you're completely right. That's the notion that is out there.

it's important to note it.

Kubescape, right, is an open source tool that we have created to help security engineers, security architects, DevOps and DevSec teams to basically be able to scan their clusters very, very quickly against misconfigurations, vulnerabilities. It started with a very, very basic and simple task to simply scan your cluster against the NSA and the CISA.

hardening guidelines for Kubernetes cluster. It was published I think in 2021 and we were the first ones to actually translate it to an automated set of tests. And I think that was also why it was adopted so quickly. And you know once we saw like the adoption and we got people asking for more and more and more.

Shauli Rozen (03:05.121)
It's kind of amazing how it grew from this simple scanner to more of a platform, more functionality, more things. And today, you know, it's actually quite a robust open source security platform, having everything, you know, maybe except the control plane and the UI and things like that.

Jeremy at Firetail (03:23.081)
Mm -hmm. Or workload protection. Is workload protection part of Kubescape as well, or is that sort of separate?

Shauli Rozen (03:30.305)
So the workload protection is more part of the ARM platform on top of Kubescape, but still our workload protection is using Kubescape as the sensor that it is using. So everything which is installed in the cluster is still open source.

Jeremy at Firetail (03:35.337)
Okay. Okay.

Jeremy at Firetail (03:43.88)
Okay.

Jeremy at Firetail (03:49.736)
So the deployment model for Kubescape is that you embed it within the cluster as it goes live into production or as it goes through deployment.

Shauli Rozen (03:58.497)
So there are two models for Kubescape. It can be deployed as a CLI, you know, a GitHub action or a CLI in the CI -CD. But the more popular option that we're seeing more and more is deploying it as an operator within the Kubernetes cluster, basically living within the cluster and seeing everything that is happening in the cluster and continuously monitoring it.

Jeremy at Firetail (04:00.903)
Okay. Yep.

Jeremy at Firetail (04:21.703)
So help me understand what is an operator because in the Kubernetes context you hear about daemon set, ingress, egress controller, sidecar, operator, like all these things that I think are terms that we hear all the time. But again, like I'm no expert on this stuff. I don't really understand the difference in them to be honest.

Shauli Rozen (04:41.025)
Yes, so it's a very good question. An operator is just a term or a way to define things within Kubernetes, but on a nutshell, and if you need to simplify it, it is just another application.

It is a special application in the way that it can create Kubernetes native configuration files, which are called CRDs, and it can read them, but eventually just an application like any application. So, and it has a way to deploy itself and a way to configure itself, but all in all, it's another application running in your cluster.

and it can run as ports, it can run side cars, it can run daemon set, and all of that is available. The Kubescape operator is based on a few ports that are running in the cluster, as well as a daemon set, which is an eBPF -based daemon set that is running on every one of the worker nodes.

Jeremy at Firetail (05:41.061)
So EBPF is again, another one of those things that I hear around Kubernetes that's like almost like a magic buzzword. You know, every solution coming to market right now is based on EBPF or some way. If you could simplify it, what is EBPF? Because I hear, I know that, you know, I've looked up the acronym, I think it's Berkeley Packet Filter, Extended Berkeley Packet Filter, right?

Shauli Rozen (06:04.513)
Yes.

Jeremy at Firetail (06:05.509)
which suggests to me that it's kind of filtering packets in and out, which suggests to me that it's like a network layer, almost like a mini firewall for stuff going in and out of, I don't know if it's pods or nodes or out of individual containers. What's the right way to think about it?

Shauli Rozen (06:21.537)
So I would say two notions here, if I may. One is that EBPF is used, the term is used very, very often with relatively to Kubernetes as part of Kubernetes, but it is not a Kubernetes thing. It's a Linux thing. So any container or VM running Linux will have the ability to...

Jeremy at Firetail (06:41.541)
Okay. Okay.

Shauli Rozen (06:48.353)
to run eBPF programs. And as you said, eBPF is extended Berkeley Packet Filter, and the Berkeley Packet Filter is a packet filter really, really focused on networking. The extended part is where they actually extended it past networking. So I didn't simplify anything so far. Now I'm gonna try to simplify things.

Jeremy at Firetail (07:08.325)
Okay. Okay.

Shauli Rozen (07:12.769)
To simplify things, it's basically a native way within Linux to be able to get observability and track operating system level and kernel level items. So you can track network packages, the public packet filter. You can track what system calls are being run by.

different programs, what files are being opened, what network connections are being opened. So it's basically a native way to track everything that is happening in the kernel and what the application is doing and be able to get a lot of observability into how applications behave and what they do in runtime.

Jeremy at Firetail (07:58.245)
Okay, but then from an observability perspective, what's the actual filtering happening? Because if you're just observing things, you're maybe not blocking things or stopping them, which suggests to me that there must be some logic that kind of ships with it that tells it like, okay, these types of things, I also want you to block and not just observe.

Shauli Rozen (08:18.465)
Yeah, so there are different levels where it can happen. The eBPF program basically intercepts some of the system calls and then returns an answer instead of them. So it can also block and actually create enforcement and things like that, even though the main use case today is for visibility.

Now, the EPPF program itself takes that data and can take it out to the user space where you can do all kind of logics and that's where many companies do the blocking and do all of the different, you know, more advanced manipulation on top of it.

Jeremy at Firetail (08:59.173)
Okay, so it's very much like an EDR model using eBPF to gain the level of visibility and observability that you're looking for, right? If I draw the analogy between like a CrowdStrike Sentinel -1 that sits at the endpoint operating system level, this is a Linux specific, very applicable for a Kubernetes environment that draws out the same type of data that we're looking for. And then to your point, you draw it out to a central location where it's kind of, you know, logic and detections are applied and then certain actions are, are,

Shauli Rozen (09:08.001)
Yes.

Jeremy at Firetail (09:29.573)
automated or triggered.

Shauli Rozen (09:31.425)
exactly true and part of our claim of fame and not only ours you know some other companies is the fact that you know it's technology that is more fit for container and communities based environments than the legacy agents that we used to run, kernel agents that we used to run.

Jeremy at Firetail (09:48.229)
And why is it that it's more applicable for these containerized environments? Is it just lighter weight? Is it easier to ship? What's the logic there?

Shauli Rozen (09:55.905)
So one of the things that is much, much easier to do within Kubernetes is to deploy those agents, right? You use a daemon set and then those agents are deployed very, very easily. Since the nodes are very small, you need to be much more lightweight. The legacy kernel agents are usually much more intrusive and much more demanding on CPU and memory.

But then also, you know, the level of the events and the change in the environment is much, much higher in terms of its frequency than, you know, the regular endpoints that we're using.

Jeremy at Firetail (10:37.509)
Awesome. Thanks for that explanation. I feel actually 50 % more educated on Kubernetes security than I did at the beginning of this conversation. And we're only like 10 minutes in. I want to kind of take a little bit of a different line of questioning for a second. So you released this thing. When was the initial release? And kind of more importantly, why did you decide to go open source from the beginning? Because it sounds like there's a lot of value and a lot of...

development effort and intellectual property and thinking that went into what you built with Koopscape, what led you to the open source decision?

Shauli Rozen (11:11.745)
What led us to the open source decision first and foremost was who we were targeting with this technology. When we were speaking with companies using the cloud and utilizing Kubernetes, when you speak with the security teams, we always saw that one of the biggest challenges in applying

a runtime -based Kubernetes and cloud security objects and solutions. And you know, we spoke about some of your companies that you worked for before. When you, like, when it's not an agent -based, it's one thing, but when you run an agent -based solution, which I feel is a must for true security these days.

security teams got a challenge of getting them through DevOps. The DevOps teams that are actually, they are the ones who need to deploy it in their clusters, they need to manage it, they need to monitor it, they need to feel that they trust that solution that is deployed in the cluster. That was the main challenge.

So we decided to open source Kubescape because we felt like open sourcing it would be a very good way to get DevOps people to relate to it, to feel confident about it, to be able to deploy it in their environment. And also because it is an agent or an application running in your cluster,

The fact that it was open source enabled us to deploy, you know, it was successful. So it was deployed very, very quickly in a lot of places. So we also got confidence that we are not breaking environments, that we live up to the standards of performance. We got, you know, very, very quickly, we got a huge amount of testing, let's say, users that were using, giving us feedback and helping us improve it.

Shauli Rozen (13:10.209)
So those are what those were the main reasons to go open source.

Jeremy at Firetail (13:14.661)
Yeah, it's interesting. You know, we went through a similar kind of decision cycle early on at FireTail. And in fact, the very first things that we built were open source as well. And I will say we had a similar kind of rationale for what we released, but we found that we face some struggles along the way in the sense that, you know, we released a very, very specific set of targeted use cases with our FireTail code libraries.

basically inline blocking of malicious or malformed API requests. And one of the pushback concerns that we got along the way was, I'm a developer building an application with an API, security is not my job. And frankly, don't come talk to me about security, go talk to the security team. I'm curious how much of that same kind of feedback you got and how you navigated that.

Shauli Rozen (14:07.137)
Yeah, so actually we got very different feedback and I think it's the nuance of the developer versus the DevOps or the platform teams. I find that DevOps teams and platform teams care about security much, much more than people give them credit for.

and they are working very much in tandem with the security team. They don't like hurdles. So, you know, they don't like to solve tickets that don't make any sense because, you know, there is no value around them and it will just create them work. But that's why you need to think, they like the engineering point of it, right? They like the understanding, you know, how a potential attacker will get into their environment.

they like to kind of like do this thing and this game in their minds. And I do think it's becoming more and more applicable to actually go to platform teams with security products. What is, I'll tell you what my struggle is. My struggle is that the budget eventually is a security budget. So we need to engage the budget orders as well.

Jeremy at Firetail (15:18.519)
Mmm.

Shauli Rozen (15:22.977)
And there is sometimes a bit of a cousin there between the DevOps and the security that we need to bridge.

Jeremy at Firetail (15:28.406)
Yeah.

Jeremy at Firetail (15:32.182)
So I'm curious, how has that informed our most strategy over time? Has that changed the product roadmap? Has it changed the messaging, all of it? How has that played out?

Shauli Rozen (15:43.137)
Yeah, it changed everything. We became a security first, DevOps first company, and focused on bridging that gap. Suddenly we understood that this gap between security and development, DevOps and development, is something that needs to be bridged. And that's the main value of our product. We help security teams identify the top issues. So...

stop sending false activities and false tickets to your DevOps. We equip them with the ability to give the DevOps the exact solution that they need to deploy in order to solve things. And then the entire relationship becomes much, much more valuable. And today, we sell to security and we will go into the organization through security. They will understand the value. And I think one of the amazing things that I've seen...

in the last year or so, even two years, is both of those sides, the platform teams and the security teams, each made a lot of road towards the other area. Like the security teams today, they understand DevOps much, much better, the DevOps team understand security much better, so we actually see this coming together happening in many organizations, not all.

Jeremy at Firetail (16:49.333)
Mmm.

Jeremy at Firetail (17:01.365)
Well, that actually brings me back to something that you said early on in today's conversation that I wanted to revisit, which is that cloud security and Kubernetes security are coming together, I think much faster than a lot of people realize. You made a comment at the beginning that you consider yourselves to be a cloud security company. Yes, with the heavy focus on Kubernetes, but really a cloud security company first and foremost. Talk to us a little bit about how you see that convergence playing out with your customers and.

maybe with the broader landscape as well.

Shauli Rozen (17:35.009)
I'll quote someone else, he's one of my team members. He said, you know, doing cloud security without intimately understanding Kubernetes is like doing endpoint protection with no access to the kernel. It is somewhat like that, right? Kubernetes is the operating system of the cloud. So connecting all of the cloud configurations and all of the things that happen to the cloud.

to intimately understanding what applications are doing within Kubernetes clusters and how they are configured and what kind of security hardening they have in the cluster, it's really, really, really critical to really understand the risk in the environment. And I'll just give like a small example, you know, just to give context. Let's say you have a workload, you know.

Jeremy at Firetail (18:18.994)
Mm -hmm.

Shauli Rozen (18:29.217)
all of the CSPM, they identify attack chains, attack patterns via the configurations of the cloud. But to be very simplistic, a configuration in Kubernetes might block something which the Kubernetes of the cloud does not see. So for example, a second profile.

or a specific security context that is applied within the Kubernetes 11. So those are things that you need to see all of that in order to really understand the security of a specific environment.

Jeremy at Firetail (19:05.072)
Interesting. And it brings to mind like a broader question, right? So I've been in the cloud security space, you've been in the cloud security space for a while. We've seen a lot of kind of product convergence from the vendor side, and we've seen the development of these attack paths. You know, frankly, when I started working in CSPM in 2016, there was no attack path. It was basically individual resources, individual misconfigurations. And then I think the space kind of grew.

really to the same type of problem that things like vulnerability management faced in the past, which is that you end up with a list with more items than any human could possibly process and with no context around it. So my open port 22 over here is just the same as my open port 22 over here, even though this one is staging and this one is production. And this one has dummy data and this one has customer data, right?

And so we get this kind of like lack of context over time. And so the cloud security space has started to evolve, right? You get the identity overlays, you get these attack path development. How do you see beyond the fact that Kubernetes is kind of the operating system in your words, how do you see this platformization playing out? And is it actually delivering better security outcomes for our customers?

Shauli Rozen (20:00.705)
this.

Shauli Rozen (20:24.641)
I think there are two things to address there in my mind. One of them is how we evolve and get more data and more context from different products like runtime products, like our products, to actually combat this challenge that I completely agree with of overwhelming people with...

and tickets, exactly like happened in the availability space. And today we are talking about, we are always shrinking and trying to be more precise with the alerts and the issues that we give our customers. So we started by combining those individual misconfigurations into attack patterns. Now using Kubernetes context and runtime context, we can actually prioritize those even further to actually attack patterns

that are impacted by runtime information and also create remediation advice for them based on what applications are actually doing and continuous hardening. So I do think that there is a convergence in the sense that more technology is needed. And one thing that I'm less of a believer in is platformization of security. I...

You know, I think it's a great concept, but what I feel is happening in reality is that companies say...

Platform platformization, but give you bundling. Okay, it is just like so Platformization is actually synergy if you have a synergy between the different products So you have a runtime product and you have a CSP a product and that that one feeds into the other That's that's in my mind platform ability in many many cases what they sell you is platform ability and what but what they actually deliver is is bundling and I think that's where we some

Jeremy at Firetail (21:57.163)
Yep. Yeah.

Jeremy at Firetail (22:09.099)
Yeah. Yeah.

Jeremy at Firetail (22:23.691)
Yeah.

Shauli Rozen (22:24.675)
lose track of the value.

Jeremy at Firetail (22:27.467)
Yeah, I've certainly seen that in, you know, certain contexts where when you talk to a customer and you say, well, what do you have in place for CSP admin? They'll tell you product A. You say, well, what do you have for workload protection? And they'll tell you product B from the same vendor. You say, okay, so you have a platform. Well, not really. What we have is product A and product B and yeah, we got a subscription that includes both and there was...

To your point, there was some price bundling and some kind of delivery bundling. To be fair to some of the companies that are following this strategy, you know, there are real challenges on integrating technologies and sometimes over time it may play out that the platformization really happens. But I totally get what you're saying on this side. And I certainly have seen that in the real world play out. So along these lines, when you think about CNAP, you know, kind of buzzword of the day,

Well, actually, that's not true. AI is the buzzword of the day. But when you think about CNAP, you know, what does it mean to you right now? And, you know, to this point about platformization, has anybody actually achieved it?

Shauli Rozen (23:26.113)
That's the show.

Shauli Rozen (23:35.113)
First I'll say that I was in Reinforce last week. I think that's why we rescheduled this recording and someone has managed to actually put in one of their booths, I'm not gonna say which one, AI -powered Synapse. So kind of like bringing everything together, all the passwords in one place. Yeah, exactly, exactly. So Synapse, I'm...

Jeremy at Firetail (23:55.016)
Yeah. Good job by their marketing team. Yeah.

Shauli Rozen (24:06.273)
To be honest, I'm not sure whether it's a category, a general category, or a product. I'm not sure, and I know many companies, even us, considered calling our platform a CNAP, just because everybody says CNAP. But the question is, if you look at Gartner, the people who coined that term, it's...

In my mind, it's a bit of, Synapse is everything you will ever need to protect your cloud. They put SCA in there, they put IAC, they put CWPP, they put cloud detection response, they put container scanning, they put CSPM, of course.

Jeremy at Firetail (24:53.672)
Of course.

Shauli Rozen (24:54.561)
And they put CIEM. So all of the different initials, they all come together in a certain place. Now, I'm not sure that...

Regardless to the fact that I'm not sure if anyone is providing such a solution as a product, I'm not sure it exists. I'm not sure there is anyone who can consume it as one product. You know, just because like the different users in the organizations that will use different things, there's not always synergies between all of them. So.

Jeremy at Firetail (25:17.512)
Yeah.

Shauli Rozen (25:29.569)
So I'm still waiting to see how it's gonna evolve. I do think that there are places where you can platform and create this platformization around mainly between runtime security products and configuration security product like Posh. I think.

And you know, I'm building my company based on this belief that there are huge synergies between runtime information and the runtime security product and posture products. And you can use a lot of runtime information to create better posture product and a lot of posture information to create better runtime products, right?

Jeremy at Firetail (26:08.455)
Yeah.

Shauli Rozen (26:10.721)
So I think that's where the synergy exists. But I think Synapse took it a bit too far, going all the way to the left into SCA and serverless and not serverless. It is just, I'm not sure there is a need for that type of product.

Jeremy at Firetail (26:33.157)
You said something earlier in your answer there that I would touch on, which is that, you know, I've done an analysis of this space. If you look on the Firetail blog, you can see a post about the evolution of cloud security. I looked at this problem going all the way back to 2022 when quote unquote platformization hadn't even been said as a word around the space yet, but we were seeing vendor consolidation around particular categories and kind of mashing them together. And by the way, fun little sidebar for anybody in the audience.

CNAP, coined by Gartner, was a replacement term for CNSP, which had been coined by a vendor. And I think Gartner took it as an offense that a vendor had dared to try to define a category, even though in my mind, CNSP, I thought was a better term, but we'll leave that to the side for a second. But the point that you raised that I want to touch on is that exactly as you said, these are different buyer personas. Things like SEA and IAC,

that are very kind of shift left activities in your build and design pipeline, maybe there are true DevSecOps organizations where this is all the same audience and the same user and the people that are involved in consuming the data have the same backgrounds and understanding. But in larger organizations, that is rarely the case. And so you could build all of this functionality into one platform.

And then I guess your best argument is that you're going to have multiple buyer personas within the customer organization and multiple user personas who are consuming the data. And maybe that's true. I don't know. We face this problem with APIs where, you know, APIs are kind of this funny thing because they're part of an application. They live on a network. They're almost always deployed in the cloud. They're affiliated to an app. And so we look at kind of what the app correlation is, but then they also generate these like log files.

either coming off of network infrastructure on the cloud providers or coming out of the application itself. And these are like different users and different user personas. And so we produce half of our product designed for the application developers to help them understand where they have misconfigured the API from the design perspective. And then half of our application for the security teams for detection and response purposes and like overall security posture management of APIs. But it...

Jeremy at Firetail (28:51.329)
But we see that tension even on a very small scale. And when you apply that to a larger product like CNAP, I can totally relate to what you're saying. Like, who uses this thing?

Shauli Rozen (28:59.161)
Exactly, exactly. Think about a JP Morgan security team. There are network security engineers that are only in charge of the network, right? And there is AppSec and there is infrastructure. So it's very hard to serve all of them in a single product. But again, I do think there is value to bundling. I'm not going to...

dismiss that, you know, there is different hurdles that it solves. But I think it's about, you know, what me as a product enthusiast, as someone who is very passionate about product creation and security, I'm always thinking about what synergies I can create between different things and how can I productize.

Jeremy at Firetail (29:51.839)
That makes a lot of sense. What are you most concerned about with cloud security right now? What are the things or the problems that you're seeing either for yourself or out in the world or for your customers that you think are threats or risks that people aren't thinking enough about that you guys are focused on at Armo?

Shauli Rozen (30:12.065)
I think one thing that I'm concerned about, to be very, very honest, is that people are not concerned enough about cloud security. I spoke with a CISO, really just a couple of weeks ago, and he told me, and I can completely get where he's coming from. I was talking with him about our runtime detection and response capability dedicated to cloud and Kubernetes. I was so excited.

Jeremy at Firetail (30:19.679)
Mmm.

Shauli Rozen (30:40.289)
And he said, well, cloud attacks don't happen. And no, think about it, right? Think about back in the days of EDR, we had, I think it was NetPathia, they call it, it crumbled down entire organizations, so people were scared. I did an EDR right now. And then we had like the...

Jeremy at Firetail (30:46.301)
What?

Shauli Rozen (31:09.569)
with your data breaches like very big data breaches that caused a lot of demand for data security. If you think about major breaches in cloud environments, either they are kept relatively quiet or people don't consider them to be a cloud attack. They think about it as a general breach. And I think that's, in my mind, that's one thing that is, I think there is a bit of a...

maybe also an education thing, the shared responsibility model. People are kind of saying, yeah, well, I have Amazon, I have the basic check marks set for me, I'm good. And we know that, you and I know that it's not the case.

Jeremy at Firetail (31:54.716)
Yeah, I mean, look, I tell anybody if you think these attacks aren't happening, you should actually set up just a test environment and apply just like basic configurations or minimum security configurations to it. Make it disconnected from everything else and then just watch it. And you don't have to wait, you know, 15 minutes, 30 minutes, one hour, and you'll see everything is scanned. Everything that you stand up in any cloud environment is scanned.

Shauli Rozen (32:08.545)
and wait.

Jeremy at Firetail (32:22.844)
And if you leave anything in an unprotected S3 bucket or you leave an RDS incident exposed, like that will not only be found, but it will be actively probed, attacked, et cetera. So I'm kind of with you on this point. And we see the same thing with APIs, by the way. You know, we're a small company with 13 people and we put APIs online for testing and they get traffic within three minutes. No DNS name. We're no brand name of any note, right?

Shauli Rozen (32:46.273)
Yeah.

Jeremy at Firetail (32:50.78)
just a random IP address coming off of some AWS infrastructure component. And it is getting scanned within three minutes typically. So I'm with you a hundred percent on this, Shaoli. Awesome. Well, it's been a great conversation today. I've really appreciated your perspective and thank you so much for taking the time to educate me on Kubernetes and Kubernetes security. I really appreciate that.

Shauli Rozen (33:11.297)
Thank you.

Jeremy at Firetail (33:12.891)
For those who are listening, where can they find out more about Coopscape, about ARMO, about you, anything like that if they wanna follow you and find out more about what you guys are working on.

Shauli Rozen (33:22.849)
Yeah, so all of the above are luckily unique enough to just Google. armaseq .io is our website, Kubescape. Just Google Kubescape, you'll get to it. I really encourage you to do that. And also myself, not too many Shauli Rozens out there in the world. I'm happy, reach out to me in LinkedIn. I answer anybody who reaches out to me, even those kind of like...

Nagi Vendors because you know I'm also one of them so I'm trying to tweet people as I would like to be tweeted and yeah so thank you so much I really appreciate the time.

Jeremy at Firetail (33:51.163)
Ha ha.

Jeremy at Firetail (33:55.067)
Hehehe

Jeremy at Firetail (33:59.035)
Fair enough.

Jeremy at Firetail (34:03.385)
Awesome. Well, Shauli, thank you for taking the time to join us here on Modern Cyber. For those in the audience, thank you for listening and remember sharing is caring. Like, subscribe, share it with a friend, coworker, tell them about the show. If you've got a minute to rate and review that is greatly appreciated. Otherwise, we will talk to you next time on the next episode of Modern Cyber. Bye bye.

‍