 Welcome to this OpenShift Commons briefing. As we do on Wednesdays, we talk to folks who have built certified operators. And Sistig has been one of the very early adopters of the operator framework and the operator pattern for using their tooling on OpenShift and Kubernetes in general. We are thrilled today to have one of our favorite folks, Dan, otherwise known as Pop, Pop Andrea, and we're gonna do something a little different. We're gonna have Dan, who is well known for doing great interviews and his own pop cast, interview Loris Diagiani, and we'll figure out just where everything is going with Sistig and Falco and talk a little bit about securing and observing Kubernetes and where the future is taking us with Sistig. So pop, take it away and let's let's do some more in deeper introductions than than that. I want to adjust that. You're not looking at a pop cast right now. We're on OpenShift Live, so I have my my dear friend, the founder here. And so Loris, do you want to give it give an intro here before we get going? Sure. My name is Loris. I'm the founder and CEO of Sistig. Sistig is the secure DevOps company, and we offer visibility and security products. We were born as an open source company, and we apply deep visibility to offer essentially security products and visibility products for Kubernetes, cloud native and containers. And taking off the podcast and putting on I'm the field CTO at Sistig, and I work with Loris and strategic accounts and strategic partners like Red Hat to bring your dreams when it comes to observability and security and visibility in your tools to fruition. I was employed 20, I think, of Sistig, and I remember that interview like it was yesterday. I had an interview with Loris, and it was really a great time, but I think we should kick it off, Loris, in terms of I'm sorry, did you want to say something? No, I was just saying it feels like we've been working together forever, so I don't know about employee 20, but definitely we've been partners for quite a bit at this point. Inch by inch, we'll get to that in a little bit too. So I want you to tell me about Sistig, I mean, just tell me about how we started, like, you know, what is Sistig and tell me how we started? Yeah, sure. So Sistig started in around 2014. It's my second company. My first company was called Ace Technologies and was the commercial entity behind an open source network analyzer called Warsha. If you've, people in the audience have done networking and packaging capture, they might have heard about Warsha. It's a very popular project that I started contributing to when I was very, very, very early on when I was a student at a university in Italy. So I've done essentially open source since 1999, when open source was still something weird, you know, very different from today. And the first company was acquired, I started in 2005, it was acquired in 2010 by a bigger company called Riverbed. And at the time we were doing, we had a pretty sophisticated product suite for visibility and performance management of applications based on the torpedoes, which is what I've done my old career before, which was great, but clearly the world was changing, you know, the world was moving toward cloud. AWS was starting becoming popular. A little company called the dot cloud was renamed into Docker and the revolution, you know, of which we are part today was really at the very beginning and it was clear that this was one of those major shifts in IT. And this dig essentially started with the idea of applying the same visibility, the same richness, data, the same context that you could get with packets in the previous generation, and you couldn't anymore because you cannot use the spam port of the router when you're renting instances from AWS, you cannot capture packets when you have, you know, like 500 containers running on a single machine, and there's, you know, no place on the network to get what these containers are doing. So from one point of view, packets are rich in information, very versatile, and allow you to like in a very horizontal way, you just see it somewhere on the network and you see everything. I used to say packets never lie, you know, but how do you do that in a world of containers, orchestration, Kubernetes, OpenShift, and in a general way, you know, modern cloud-based applications. And essentially, we started the company with that in mind. Essentially, the question was if you could start with a black sheet of paper and really create the solution that is perfectly tailored to the new world of containers and orchestrated containers, what would you create? How would you approach this from the technical point of view? And that's how our original technology based on capturing system calls with containers in Kubernetes context, actually, even before Kubernetes. So orchestrator context was born, and now, you know, in 2020, I'm here doing this interview and talking to you, Paul, and quite a bit has changed and quite a bit has grown both in the ecosystem and at Sysdig. Awesome. And again, from this basis, I think let's talk about like what is Sysdig now in terms of like, you know, specific use cases that, you know, I can talk about a couple if you'd like, because, you know, you and I have worked on some of these use cases with, you know, the product teams and also like the implementing teams and all of that. But there's a couple that come to mind that you can say like you use specific use cases around Sysdig. Yeah, absolutely. And by the way, yes, feel free then to interject here because you spend a lot of time essentially talking to, you know, end users. I learned under your wings, my man. So like, I've been with you those things. So like, anyway. But typically, I like to, when I describe what Sysdig does, I like to use three words, build, run, respond. This is essentially, I like to describe it that way because it's like in life cycle of modern applications is probably one of the things that is changing the most, you know, compared to what we were doing before with monolithic applications running on physical hardware or virtual machines and releases that were happening, you know, every six months or every year or something like that. Now we essentially all develop applications through a pipeline, right? Using CICD and then in following typically, you know, like opinionated flows that go from, you know, the code in your laptop, a Git repository, typically building container images that go into some image registry and then these images go and are picked by an orchestrator and implement applications that run in production. And there are steps and gates and processes here that are different, you know, for every organization and for every team, but also have stuff in common. At the build stage, it's important to make sure that we shift left as much as possible, that our code, our containers, our components are validated for functionality and especially for security, for they move forward in the pipeline and they go to the next stages of the pipeline. And here, for example, container image scanning, validation, configuration checking are all things that are very important and then CISDIC does. Then typically our images are run, you know, they can be run into a development environment, they can be run into a test environment, they can be run into a production environment. Typically these environments have different profiles and different properties, but they share the need of you and your team being able to first of all understand what's happening. So insights and visibility is really the key here. And then protection, especially if the containers are run in production environment. And runtime protection is something that we are seeing becoming more and more important. And CISDIC is focused here strongly, not only from the commercial point of view, but from the open source point of view through our tool that we, that now is part of the CNCF and incubation stage, FALCO. And FALCO is really, we'll talk a little bit about that later maybe, but it's really like the de facto solution for runtime security and runtime protection for containers. And then, go ahead then. No, I was just going to say, I mean in terms of, you know, we're going back to the build, run, respond. I mean, if you look at this from, you know, the image scanning as a step one, right, and you're, you know, bringing these apps in production, you really need to, and I was on OpenShift Live with Chris Short before and we ran through that whole process, right, this whole, you know, from build all the way to, you know, to the run and from a forensics perspective and then this post-mortem capability, right? So even from like container, like forensics use cases, and again, I, you know, I mentioned this very large investment back then, you and I spent a lot of our time together, you know, initially trying to like prove out the value of SISTIC. There was, you know, this use case where, you know, they wanted to have, you know, visibility, but then also have, you know, to build like new rule sets without having to involve the vendor, right? You know, so things like building mitre attack framework. So those use cases is super, super, you know, high in terms of somebody touching a directory, understanding what they did in this, you know, you talked about this, you know, SISTIC calls don't lie, right? Being in a container and be able to have this, they're not black boxes anymore, you now have the ability to say, this thing happened. No other tool in the market can do that. I'll put us up against anybody out there, no matter what. Yeah. And you were saying SISTIC calls never lie. Actually, I said, I said originally that it's never lie, but you're right. SISTIC calls never lie, and they lie even less because they're closer to the application, right? So let's talk for a second about what we mean by SISTIC calls. A system call is every time you are running an application, a process, a container on a Linux box, but not only Linux, any operating system, these applications need to do something other than just computing, right? They need to talk to the external world, they need to establish communications, they need to read and do input output from files. So there's a bunch of stuff that is going on, and typically this requires the intervention of the kernel of the operating system because reading a file essentially for an application involves telling the kernel, okay, open this file and give me the content of this file. All of these are SISTIC calls. So essentially the call technology behind SISTIC involves taking these SISTIC calls, finding clever ways to capture them in a way that is from one point of view super granular, but also very horizontal. So you don't have to worry about instrumenting every single container, linking libraries through your application and stuff like that, but you just essentially through a number of different ways tell essentially the operating system, okay, I would like to get all of this data in a very efficient way, give it to me, and then you're able to understand essentially all everything that any single application does in terms of data, and what data is accessed and what is read and what is written in terms of network communications, in terms of users, what they're doing because every time a user executes a command, changes the configuration, logs in somewhere, this generates SISTIC calls that are like the footprints, you know, and by looking at these footprints, we're able to reconstruct everything. So packets never lie, SISTIC calls never lie. Which is a natural segue into, okay, we talked about Falco a little bit, right, and I want to talk more about like what it is, what it does, the use cases, again, that's our open source. I want you to talk to us about what is Falco. Yeah, I already said multiple times that what we do at SISTIC was inspired by our previous live with packets, right, and this is true for Falco as well. As I was saying, Falco is the defector tool for runtime security in Kubernetes, and Falco is able to sit on a host, get this granular system call insights into every single process, and therefore, every single container running on the on the host and takes all of this stream of system calls that can be, you know, hundreds of thousands, sometimes millions per second, and puts a rule engine on top of that, so that you can essentially be notified based on conditions or anomalies that happen on this stream of system call. Said like that, it's a little bit, you know, like harsh and technical. Right, it's a little, I mean, if we boil it down to like what it does and what does it address, that's the big thing, because it does, and again, it's so hard, it's so hard, because this thing does so many amazing things, but let's just boil it down to like, what are the pain points of what it does? Like, what is the pain points and what does it address, right? Yeah, so with Falco, you're able to be notified at runtime as stuff happens of an arbitrary number of anomalies that happen on your Kubernetes cluster. Let me give you examples. I don't know. Somebody has gained, you know, access to one of your containers and is executing something. Data is stolen and exfiltrated from your infrastructure. People are changing your configuration to do something with your cluster. Somebody has just started, you know, a set of Bitcoin miners in your infrastructure. These are examples of stuff that Falco can detect. Of course, you know, it's much bigger than that. We have a rule set with hundreds of rules now that are essentially driven by the community. But this gives you a flavor. Essentially, Falco is like, very often, I compare Falco to the security camera for your Kubernetes cluster, right? It's very important when you have, you know, a house, a piece of property that you care about to have blocks at the door. In Kubernetes, you can implement locks in different ways through admission controllers, through network policies, through all of this kind of stuff that essentially allows you to, I don't know, block somebody from entering. The admission controller prevents an image from entering your cluster. And that's, you know, like the lock on your door. But once, but you still want, even if you have good locks, a security camera that allows you to understand if somebody is snatching, maybe from the window, you know, maybe from the chimney, hopefully Senna, you know. But at the same time, you need to understand if something managed to get in in a way that maybe you don't expect. And if somebody got in, you need to understand essentially what they did. And that's what Falco does. You deploy Falco through like a demo set, or through a home chart. It goes through any configuration. You start getting data and Falco starts in the new A. Somebody got in and this is what they did. And this is where you need to take a look, you know. So that's Falco in an action. And you know what I love about it? The Falco rule set is a good basis, right? But there's events and there's rule sets and there's outputs that you can do, right? You can output as GRPC. You can do it as JSON output as HTTP. I mean, that's the beauty of it. And again, it's because it's an open source project. If there's something you want to contribute to, which again, everybody out there, go to Falco.org. We have a Slack as well. Contribute to Falco. There's a lot of cool stuff that we're doing with, you know, people in the community. I mean, just the other day, we're working, one of our people Lorenzo was working with Alex Ellis to help do like arm 64 support, which is crazy, you know, like for Falco, it's, you know, the playing around with this stuff is just getting involvement from a community makes our product better. Very much the same as our lovely host here today from Red Hat. I mean, that's, you know, how the whole open source ecosystem starts is, you know, people contributing to the things that they're passionate about. I'm sorry to cut you off there, yeah. No, yeah, absolutely. And yeah, from, I believe that the tool like Falco really fits well, the dynamic of having a community, because if you look at what Falco does, and by the way, we're talking about packets. When I started Falco, I was inspired, I don't know for the older people in the audience by tools like Snort, or Suricata, or Broso, intrusion detection systems, you know, for network packets. And I, you know, I've been in the space for long enough to witness essentially how well the model of having a powerful, efficient rule engine fit with the community. Because once you have an engine that is flexible, that we maintain essentially as a core maintainer team that can be deployed easily, and that you can trust in terms of performance and flexibility and integrations with the rest of the ecosystem, then any member of the community is free to customize it for themselves and the specific needs, because essentially it's a rule engine. From this point of view, we can compare a little bit to OPA, which is a generic essentially policy engine, and then you can customize it for your needs. But this customization nature also generates contributions from the community, which means that you will be guaranteed that your security camera always has the best detections, because you have a whole community of people that be detections for themselves by customizing it, but then contribute some of these back to the community. And there can be a relatively little core team of developers that focus about making this super, super efficient. For example, recently I've been involved personally, it's always been a passion of mine on the rule engine, you know, and trying to find optimizations for the rule engine. But at the same time, while I do that, and I go very deep, a user can really come and be part of the community and contribute just by creating a rule for a specific PCI compliance check, and that will become a benefit for the rest of the community, then check after check after check, Palco becomes an extremely powerful tool for PCI compliance that everybody can use, and then for MITRE, and then for other compliance standards. I mean, my belief is it's the facto kind of tool for runtime security on Kubernetes OpenShift in general. I believe it. And I think we got some questions from the, Diane, is that what you're coming on to remind me about the question? Yeah, I was, yeah, I'm not so sure how my bandwidth is, so tell me if I'm great enough. But actually, one of the things that I'm curious about too, and the thing that Sysdig and Falco save us all who are deploying containers and applications and services on Kubernetes and other places, is working with the compliance officers. And because historically, that's where you have to build the trust in order to be allowed to deploy your applications and your services. And so, I think one of the things that Sysdig has done for us in the community is giving us a way to build that trust with the IT audit and the compliance officers. And that has been the besides the fact that you're doing all this wonderful stuff in the open source world, that if you didn't cover our behind for that aspect of deploying applications, we would have to be doing it ourselves. And that's a real heavy lift to do without something like Sysdig. So that's I think one of the huge value propositions for your corner of the market and that you've done us a huge service. And so that that for me, I love the packets, never lie. And Syscalls never lie. I'm not sure we can prove that, but maybe you guys could. So that that's it. So maybe a little bit about because I know the conversation with compliance auditors and folks like that, how you help people have those conversations to trust the tooling. I think that building that trust inside of an organization, I know because I'm old, I can remember having to go through log files line by line with auditors like yes, my database is really, you know, doing this and those transactions really are logged. But maybe if you could talk about your experience helping people do that and having those conversations. Laura, do you want to take the first part of and I can take the second part? Is that okay? Yes. I would start by saying I absolutely agree. And one of the things, again, I've been part of this industry essentially, you know, from the beginning, you know, I was there when Kubernetes did, you know, release number one, I've been following definitely the evolution of OpenShift since pretty much the very, very beginning. And what you're saying is clearly insightful because more and more things like compliance or forensics is another one become more important when talking to people both in the community and in the industry. And this is clearly, in my opinion, one of the best indicators of the fact that our ecosystem is maturing. Right? When we were at the beginning, like 2014, 2015, people were mostly worried about container image scanning, which is the first check that you need to fill, even if you're not really going into production, you know? And then you really need to start running, you know, because maybe you're doing experiments, you're doing just applications that are not critical. And then as your application scale become more critical and more developers and more users, then you start, okay, you know, runtime becomes important, compliance becomes really important. You know, if I need to replace my legacy infrastructure with one that is based on containers and OpenShift, I need to make sure that I have the same compliance checks, you know? And this kind of stuff that maybe is not as sexy as, I don't know, working with the latest and greatest features in Kubernetes becomes really, you know, a critical thing. So I see these increasing interest in compliance. And as a consequence, the growth of a company like CISD is a very exciting indicator of the maturity of the Kubernetes market. And Diane brings up a great point. And again, it's like, I think right now, as we're seeing this, and again, you know, RedHead's seen this as well, it's a cultural shift. Without a shadow of a doubt, right? The security teams were here, network teams were here, and then the DevOps teams were here. And so amalgamating the two teams, what do you need? Do you need to embed this security? So if a developer is like, well, why are they scrutinizing my builds? Well, it's because we have a common set of compliance rules that we're going, or, you know, from a built perspective or from a runtime perspective, might be, hey, the reason why we have to do this is your applications need to be compliant when they're pushed into an environment from a runtime perspective. And so from our, it's kind of our take on it is that, you know, we're actually helping to unite those two teams. Because we're saying this is a common set that you're going to see. And here's a, you know, base to see they're from MITRE or some PCI compliance and tags from that perspective. That's been part of our enterprise tool as well, is having this workflow that kind of provides that, you know, stream seamless kind of view that the developer can see vulnerabilities or like at runtime perspective, they can see it, but it's all dictated from the same, they're all speaking from the same script, so to speak, if that makes sense, Diane. Because the pipeline, oh, sorry, go ahead. Yeah, it definitely makes sense. And I think the interesting thing for me is I probably first came to Sysdig and other tools to debug my applications more than compliance. I mean, I think the first, when developers first approach Sysdig or admins or network people come in, they're using it because they need the tools to figure out the stuff and the maturing of the audience for whom these reports and tooling and the trust issues have to be built out, shows just sort of the next level of the Kubernetes ecosystem. It's an instant response. And again, if you think about, if you extrapolate that term even to from a troubleshooting perspective, right, you talk about this DevOps function, somebody's trying to debug why their pod crashed. I could tell you right now the number one blog we have out there is how pod crashing. And we have a blog we wrote how to troubleshoot that with Sysdig. Now, think about now taking that from a runtime prospecting and figuring out somebody terminal didn't do container and wrote to the Etsy director that's hitting all types of compliance on your production level. I want to know that's a PCI compliance bench. That's something that's necessary or the underlying host itself isn't compliance. Now, again, if you're using OpenShift, they're going to plug for OpenShift. You already hardened. You already have some of that indemnity, right? So it's, you know, I'm not getting paid. Diane's not sending me and Laura to check this. I got no budget. I'm on the open side. I got no budget. Yeah. So do you want us to go into the next question or because I see one about cloud scale, Prometheus monitoring as well? Yeah, that I'd be curious about to hear more about that too. Yes, myself. So Laura, you want me to get the first half and then you get the second half? So it's up to you. Sure. Is the question just general overview of what we do? Why don't you start with that? Because I don't think a lot of people are aware of this offering. A little overview would help really nicely. Yeah. It's one of the other tools and ecosystems that has taken the IT world by storm is the converging of visibility and monitoring into finally, after decades, an open standard, an open protocol, an open way to export and collect metrics and a way that can be, you know, embedded similarly to Falco inside the platforms and inside Kubernetes easily. And this is Prometheus, right? Prometheus is great. And the most important thing about Prometheus is that it gives us essentially common language around which we can have conversations about metrics. This common language is definitely the Prometheus protocol and the format for the Prometheus exporters, but also from QL, the query language that is at the base of what Prometheus does. And then, you know, like Grafana is a way to visualize this metric. CISD comes from a strong background in monitoring and visibility. And the way we, what we want to bring to the market in terms of Prometheus is the, from one point of view, decreasing the barriers. So making Prometheus easier to consume. And we have a commercial offering that includes essentially a bunch of exporters and dashboards that are curated and donated by CISD and that can be used essentially in an easy and natural way. The other one is the scale. We built essentially an engine, a SAS engine that is more or less infinitely scalable in terms of Prometheus that you can trust in terms of stability and in terms of, you know, throwing at it the data of even, you know, sophisticated or big infrastructures. But that at the same time, differently from most of the other, you know, commercial monitoring solutions is fully, 100% compatible and householdable with the Prometheus data that you're using today. You know, so if you're just using a single Prometheus server, or if you're using Thanos and Cortex, you can household and use CISD in a very natural way. And the other thing is we offer something that, especially for enterprises that maybe have a bigger size, has all of the integrations, ability to support, for example, teams of developers with segmented data, ability to integrate with our back and all this kind of stuff, that a bigger organization with many developers and many users needs for Prometheus. So our philosophy is always we support open source and we try to, you know, make it possible for people to really truly adopt standards and based their infrastructure on true standards. But when it's time, essentially to bring it to the next level in terms of security, in terms of visibility, in terms of proper shooting, you can trust CISD to be your partner and you can have a partner that essentially has worked with the biggest companies in the world and that's essentially a better tested solution that is fully compatible and fully householdable with your open source solution. Nailed it as usual, Lars, but I think I add one point to this. Also, we have a curated kind of hub. It's called, I just think I'll also base this as well as OpenShift out of the box. It's amazing in Prometheus integrations. And so what we are doing is adding, you know, again, as Cystic does, right, is adding even more layers to that for you to be able to like get even deeper dissemination, do that troubleshooting like Laura said, have that RBAC functionality. But also we have a curated list of exporters that you can have helm charts to be able to deploy in your environment, something called promcat.io to type that in chat, promcat.io. And basically what that's going to allow you to do is you have helm charts to deploy new things that are out there because right now what do you do? You go out there and you find an exporter and you cross your fingers that it's not going to bring your whole cluster down because it might be something like a node exporter that somebody might have really not put the testing in. We tested this, you know, some integrations were like, let's just say nginx or, you know, cloud watch metrics, whatever. I mean, we've worked with like these various teams to be able to have that going. So that's another kind of key advantage we have is this kind of curated, you know, integration along with all the amazing stuff we do to make it cloud scale from a backend perspective. So I'm sorry, Dan. Is there something else you want to say? promcat.io is new to me. So thank you. Thank you for that. I hadn't seen that one before. So that's awesome. I see why even Chad, he also mentioned security hub. Again, great stuff there. That's, you know, something that so all our FALCO rules is basically, you know, I'm sorry to take over, but that's basically where something, you know, you could have like best practicing configurations of FALCO rules that you may not know about stuff like, you know, securing at CD or securing, you know, your instances that are running in GKE or, you know, those types of things or fluid D rules. I mean, you know, those things are happening right out of the box. Thank you so much, Waleed. It's good to see you, but yeah. So I think that the wonder, the beauty of the open source community in Waleed and everybody else is sort of showcasing that is, is the willingness to share the recipes and cookbooks and templates for doing these things. And I think that's, that's, and with the different approaches with Prometheus and FALCO and other things and Helm and operators, this is really one of the things that is, I think, helping with the adoption of Kubernetes and securing it and making sure that it matures in a way that we can all take advantage and build our innovations and do our workloads on it. This is something we learned, we learned from our friends at Red Hat. I mean, with, you know, Ansible Galaxy and, and the things you all are doing with operators. I mean, again, we, you know, you are the, you know, in terms of our relationship, we understand, like, you know, what, what you all bring to the table and we want to help, you know, benefit you as well. So that's what we do. Yeah. Well, and I didn't pay him to say that. So it's, it's, it's, it is the open source model. And, and I think, you know, Red Hat drinks the Kool-Aid and, and Loris, you've obviously been drinking the Kool-Aid. Oh, he's going to put on his Red Hat jacket. I got my jacket. It's getting a little cold in here, Diane. It's getting a little cold. And we're going to have to swag you out again soon here. Isn't that the one thing that's missing from all these virtual events is that there is no swag anymore? I don't know what I'm going to do for stocking stuffers at Christmastime. Yeah. Yeah. I'm starting getting long t-shirts, you know? No, I'm getting some knitted OKD hats into the cool store, school, cool stuff store at Red Hat. Hopefully in time for Christmas. So we'll send you some for being on the show. I'm wondering if you could talk a little bit about your roadmap, what you see coming down the pike for cystic or the offerings you have, or even in the evolution of Kubernetes itself, what you're, what you guys are thinking about. Yes, Walid, I know the OKD t-shirt did not appear on your doorstep as it should have. We had some customs issues. So anyways, moving on from swag to roadbaps. Yeah, I can take this one. In a general way, cystic as a company is betting on the fact that there's really, you know, at this point, there's no question that a new stack is formed. And the new stack is going to be based on Kubernetes. And the new stack is going to be powerful, cloud native, and open, and open source, and community driven by nature. So we see essentially, we were talking just now, you know, about the open source and the community approach. Not only we believe that this approach is going to be rich and powerful, but we also think that a no vendor of success will be able to escape this dynamic in the future. What I mean is, for example, insecurity, which is an area as we discussed where the cystic is really focusing a lot of energy, the legacy approach of having solutions that are built in a proprietary way, and brought to the market in a proprietary way, just not going to open anymore. You know, Kubernetes is designed as an open ecosystem, as a system based on standards, on API, on community collaboration, and that will have to be the case everywhere. So from the open source point of view, the way we see FALCO progressing is really like we are, I was mentioning before as we're designing FALCO as a very, very powerful engine that is essentially pluggable. Our goal is it should be easy for anybody, essentially, ideally one-liner to not only deploy FALCO on Kubernetes, but also create the proper pipeline of collection and processing of the data to make FALCO essentially insightful for you. And not only, like when you have the security camera, it's only good if you can do something with the data. If you're never able to look at it, it will be useful. So modularity, efficiency, and the ability to embed the tool wherever it's possible. From the commercial point of view, very similar philosophy. So we see a cystic secure and cystic monitor really evolve in a way that is as close as possible to Kubernetes, taking advantage whenever possible of the richness and power of Kubernetes. One way that I like to put this is better included. So don't go and implement some way of blocking images from going into production when Kubernetes offers the admission controller. Don't try to do whatever, like protection of containers in custom ways, maybe using weird stuff like LDP preload and so on, when Kubernetes gives you, I don't know, post-security policies or second profiles or stuff like that. So try to create a tool that brings really critical important functionality like compliance, which we're always working to enhance, like runtime security, like forensics, which we didn't really touch very deeply now, but it's very important because OpenShift Kubernetes orchestrates stuff away, right? So by the time you get a red light from one of your tools and you know that you've been attacked, very likely your container is gone. So what do you do? So all of this kind of stuff needs to be really offered to the users because it's so important and so critical, but needs to be done in a way that is Kubernetes centric and battery included centric. So from the roadmap point of view, if you follow essentially the roadmap of Kubernetes and what's happening with network mesh, what's happening with the things that have been added to the platform, what's happening with the, you know, like the enrichments that tools like OpenShift bring on top of Kubernetes, it just wants to play with that, integrate and essentially at any stage of the pipeline being able to offer security, protection, compliance, monitoring, troubleshooting, incident response. I think you're going to add really quick and then we should probably, you know, wrap it up. I think we're close to the time, but you know, in terms of just having a workflow from a security perspective, you know, this isn't also for the larger enterprise. It's also like having security as a SaaS-based deployment as well. That's not something that other vendors can do and we can, right? So we have this like, you know, essentials functionality, which are the five top five things you would need to be able to, you know, secure your environments that maybe, look, securing, you know, I'm doing a KubeCon talk, talking about how Kubernetes by itself is not secure. There's things that you need to do to secure your pipelines, to secure your runtime capabilities and Laura said, the forensics capability. So what we're going to do is new event streams, new work, easier workflows for you to be able to do that. And also for the enterprises, are there, you know, there's SMBs or the, you know, mid-sized companies that just want to be able to like not worry, that's worry about their applications as they should, we can help you from a security perspective and have this running in SaaS. Huge, you know, huge kind of advantage of SysTik. And another thing that the last one that I want to mention in terms of where we're going as an open source community for Falco and as a company, the other one is running Kubernetes is becoming standard, you know, everywhere in the data center, at the edge, in the cloud. And Falco as an open source tool and Sysdig as a company is really focusing a lot on helping our users and protecting applications everywhere. Just now, you know, I was in a call with the Falco community and we were discussing arm support, you know, in terms of being able to protect the edge, you know, because the edge is, and we'll be running Kubernetes. Oh, the cat's out of the bag now, Lawrence. We're going to have to have a lot of PRs on arm now. Oops. There we go. You just made my day. There you go. Working on that. But that's an interesting one, you know, or the cloud, you know, being able to run, you know, Falco and Sysdig on environments like, I don't know, Fargate or wherever, you know, you want to run containers everywhere. So Kubernetes is going everywhere. As a consequence, Sysdig needs to go everywhere. I think that's actually probably a great place to sort of wrap this up and maybe where, if you want, Dan, to share the resources slide that you had there so that people know how to get ahold of you all and where to find more of this stuff. And you mentioned, Dan, you have a talk at KubeCon North America. I do. Yeah, I'm speaking with, yeah, speaking with actually Booz Allen, we're going to talk about pretty much like, you know, the inherent aspects of Kubernetes that aren't out of the box secure. So being able to do that. I have a flashing on the screen as well, kind of, you know, we have upcoming things. I mean, if you go to Sysdig right now, and in terms of our partner Red Hat site, I mean, we have, I mean, we're well known for the blogs that we write in terms of releases and everything like that to take a look at that. Security on Red Hat, we actually wrote that with Red Hat on securing OpenShift. It's a very, you know, well-placed document. We appreciate, you know, the working together with Red Hat on that. Again, Loris, do you want to handle the talking about joining the community and that type of thing? Yes, join the community. Loris is there. That's all you need. That's all you need. You see the link, the links on this page, again, Falco. So first of all, we would love to see you as an open source user of Falco. Runtime security is really becoming more and more important for Kubernetes. And if you do runtime security for Kubernetes, and if you care about it, then you need to come and take a look at Falco. We are there to help you. We are a CNCF project. We have our data page. We have our weekly calls. So just go, go to the links on this document. Come, say hi. We'll be happy to chat with you. And we'll be happy to see you use Falco as a tool. One last shameless plug, Diane, if I may. And again, these bright talk webinars we do, I've done a couple with some of the Red Hat folks, some of the other people in the ecosystem. But this one's very, very cool because it's literally, you know, everybody can hear the vendors talk about stuff. But having an actual, you know, three enterprises talk about how they, you know, solve Kubernetes with anecdotal things with OpenShift and Cystic is huge. So having anecdotal pieces where it's real, it's real, where people are using these technologies in real time. Check this out on November 10th. We have a bright talk. We'd love to see you all there. Awesome. I'm saying that 2021 is the year of the end users sharing their best practices and lessons learned and events like that and like the OpenShift Commons events. Really, the people we love to hear, we love to hear the updates from folks like yourselves on Falco and Cystic and stuff. But I think the value proposition for hearing from end users is so much more real. And that's where we really learned some of the best kept secrets on how to use some of this software and how people are using it and configuring it to make their, solve their problems and help secure their system. So I really appreciate you guys coming here today. This is awesome. Listen to the podcast. You know, if you're not yet, you should be. And we'll definitely reach out and get updates as we go forward and do some more work and definitely check out Dan's talk at, yeah, I know. There's the red hat. Number one. Number one. Yep. There you go. And if you're, if you're going to KubeCon North America, you can also add on for having posting an OpenShift Commons gathering on November 17th, day zero of KubeCon. And we'll have a number of end users talking as well as updates on the latest release 4.6. And so there's going to be lots of really good content coming out. And hopefully you won't hit virtual burnout, but some of these stories are really some of the best things I've heard. So there's going to be some really cool stuff coming at KubeCon. So thanks again, Loris, Dan, and this has been a pleasure. I'm looking forward to it. And so take care and be safe. Be safe.